ADO.NET is probably the best solution for data processing in X# as of today.

[xinjie]

Hi, everyone

I should note that I only knew some VFP before learning X#.I'm hardly involved with dotnet at all.

There are some functions that are temporarily missing in X#, especially the TableUpdate() function.
My personal opinion is that this has somewhat dampened the enthusiasm of many people to switch from VFP to X#.
"No TableUpdate() ? How can I update the data then? Do I have to write extraordinarily complex code to do this?"

Of course, if you're familiar with dotnet, there may be other ways to do this. But, for me, that's a problem.

I've probably learned about the various ways to manipulate data in dotnet through AI. However, only ADO.NET caught my attention for the time being.
It really does have a familiar look to it. Whether it's a DataSet/DataTable, or a DataAdapter .

Then I revisited the CursorAdapter in X#. even looked at its source code (I just wanted to understand how it was implemented).
I executed a test that comes from: https://github.com/X-Sharp/XSharpPublic ... rogram.prg

As I followed the execution of the code, I noticed that the DbConnection property stores a standard System.Data.Odbc.OdbcConnection object when given an available connection handle for the DataSource property!

VFP programmers who are familiar with ADO.NET will already be able to understand what I'm trying to say.
DbDataTable() gets a standard System.Data.DataTable ......

I hope the experience I have shared is useful to you!

[mainhatten]

Hi Xinje,

you are absolutely correct. The vfp programs I still see make heavy use of buffering - the whole context of GetNextModified(), Get/SetFieldState() TableUpdate(), TableRevert() is/was the special sauce in vfp, as it caches part of the (nowadays remote server) tables as Selects on the local drive, an early "local first" development approach when internet was slooow.

My 2nd idea was to carry "databound coding" via X# over to Android/iOS devices, which faces by now the problem that local SQL will not work there as Advantage AFAIK is still intel only, even if X# translated into ARM IL will work.

Targeting mobile devices seems more practical using their subset of ADO.Net. Those devices get more RAM each year, so working on the local disk or in RAM is less a deciding factor, as most local data fit into RAM.

Also the early vfp way of giving direct connection to a server backend as is done in ODBC and ADO.Net fell out of favor as servers got stronger and SQL injection was not always taken care of - Web endpoints on server calling stored procs probably have been actively sabotaged if attacker can access the server "Bobby Tables" like...

When the Buffering functionality was dropped / fell in importance I went elsewhere and now only check in sometimes per year. When your code runs above OS level, you have 4 large programming environments

• Java and Dotnet with higher developer time but fast execution
  Javascript which can incur high transpilation times as well, but can JIT also
  Python with fast dev turnaround, lousy performance but easy optimization ways into C runtimes.

X# is constrained to intel desktop or server usage, so the need to port vfp is not that great as long as 32 Bit COM can be accessed in Windows.

regards
thomas