Hi Victor,

You should consider SQL passthrough. This would allow you to fetch a cursor from MS SQL and use it as the recordsource for a VFP grid. No table buffering is needed on the VFP end, since the cursor would not be connected to the back-end anyway. When you are done inserting and updating to the VFP cursor, a submit button on the VFP form could intiate a loop through the cursor, and SQL passthrough could send MS SQL any changes. Before sending any changes to the back-end, you could use SQL passthrough to BEGIN a MS SQL transactions. If the transaction updated correctly, you could use a SQL passthrough to send MS SQL a END transaction; otherwise, you could use SQL passthrough to send MS SQL a ROLLBACK. This would allow MS SQL to handle the transaction, and the loose connection between VFP and MS SQL to act as the buffer. Essentially, this is much like the way a browser submit data in a form to a web server. The web server's HTML page calls the middle tier script like VBA, .Net, Perl, PHP, vfp.dll or com, etc that connects to the database and sends the info via a SQL to the back-end database.

If you used VFP buffering 5 and VFP transaction handling, this would create a kind of double buffering and double transaction effect, since most back-end server already have buffering from the loose connection and already use transaction implicitly.

Since VFP binds into the table when making a native connection, VFP uses buffering to achieve the efficiency that is provided from a lose connection to a remote data back-end.

LelandJ