We rely on our own polished SQL Data Layer classes for handling SQL Server backend.
They are designed to use common features between SQL Server and VFP. For different commands (e.g. CHR vs CHAR) we do explicit program check that is in the datalayer class. So that upsizing to SQL Server and downgrading to VFP data are as easy as setting property of the data layer.
So we use SQL queries, which for SQL Server are execuded with SQL Server.
In other words we do not count on TableUpdate for SQL Server tables.
As for VFP free tables (we are not fans of using VFP database containers) we use table locking and TableUpdate to simulate "transactions". For SQL Server we use explicit command (SET TRANSACTION ISOLATION LEVEL SERIALIZABLE).
This design allows us to handle such situations as failed connection to the SQL Server (because of problem in communication lines).

>I would like to get your opinion on whether to use Tableupdate vs. Update/Insert, with SQLEXEC(). I am quite convinced that SQLEXEC() is a better way to manage remote data. Once I fetch data from SQL Server, I make the cursor updatable with CURSORSETPROP() and set the buffering on the cursor. I am using SQL's Identity to create unique record Ids. Ideally I would like to get the data from SQL and release the connection, till I am ready to update SQL server with modified data. It seems that I can't do that. I have to have a connection to be able to use TABLEUPDATE() from the time I fetch the data into VFP Cursor. The other alternatvie is to get the data and later use SQL - INSERT/UPDATE to update SQL Server. If you can provide me with better solution or point me in right direction. I am also playing with the idea of having most of the code as Stored Procedure (SP). I would appreciate your input on that too.
>
>Thank you,
>
>PS. It seems like, once I do tableupdate, I have to re-execute my select i.e. rebuild the cursor and make it updatable for me to be able to use TABLEUPDATE(), to synchronize the data between VFP and SQL. Is there an alternative?

Regards