- getting data from a remote data (SQL Server) into a "cursor" (what you referrred to as SQLLite).
- be able to bind "one record" of this "cursor" to a bunch of controls (text boxes, check boxes, etc).
- when user clicks on Update/Save call "TableUpdate()" and the remote data (SQL Server) is updated from the "cursro" (being it SQLLite or dataset or something else).


Strongly-type datasets do 90% of that, plus they give you Intellisense on the columns in the datatables.
I think of a datatable in a dataset as a cursor.
The last one, TableUpdate is there in datasets but it seemed kludgy to me, so I wrote my own method that generates SQL code to save any one row from a strongly-typed dataset datatable to the server.

Many people use data objects the same way, but I cut my teeth on datasets so I stayed with them.





>>>>What methods from VFP do you miss in .NET? Anything that's awkward or not very straightforward for somebody with a VFP background? I'm thinking of making a set of extension methods geared for VFP devs and I've been out of it way too long to remember much.
>>>
>>>I think if someone created a class in .NET that mirrors - as much as possible - how VFP CursorAdapter works, it would be great. At least I would love it since I love using CursorAdapter. And Mike, when you finish it, I would like you to write a side-by-side demo of using your DotNet_CA and CursorAdapter. If you don't have time, I will help you with testing and documenting.
>>
>>If that entails pushing the remote data into a SQLite temp table as "cursor" for local munging with local lookup data or other remote stores, I also think that would be the best thing to carry over from vfp. From xBase table handling:
>>- a few wrapped positioning functions seek/goto
>>- a wrapped iteration over sets [scan]
>>- tableupdate() with row and table buffering
>>- a single bound datarow from ADO.Net to bind single rec data binding [scatter/gather]
>>- some of the data discovery functionality wrapped as well (fcount, field, order, index, key, )
>> (the DD-like functions extendable to other remote backends, so dependant on the adapter)
>>
>>was the thing I was wondering about to do either in pure Cpython/cython or Ironpython/C# before encountering Lianja -
>>first get functionality working in the python version, then aim for speed with cython/C#, as much of the field/row code can benefit from compiling down to statically typed machine code. Just wrapping the ADO.Net dataprovider objects into a single cursoradapter interface targeting ADO.Net Datasets IMO would be a disservice, as the dataprovider side is the more elegant part of Dotnet, whereas the local RAM/disc based cursor is missing. Targeting SQLite Memory: can be left to specific code via property setting..
>
>Technically I am a million years behind you so I don't understand everything you say. And I have never used SQLLite so I dont know how it is used. But generally you are I are in agreement:
>- getting data from a remote data (SQL Server) into a "cursor" (what you referrred to as SQLLite).
>- be able to bind "one record" of this "cursor" to a bunch of controls (text boxes, check boxes, etc).
>- when user clicks on Update/Save call "TableUpdate()" and the remote data (SQL Server) is updated from the "cursro" (being it SQLLite or dataset or something else).
>
>Since I don't use Python and/or Lianja I don't how it relates to this.