Hans,

I wish you can read Russian, since this topic was discussed in details recently at http://forum.foxclub.ru/read.php?29,263149,265875#msg-265875

>Hi Srdjan, Hi Naomi, Hi Viv,
>
>sorry for not answering faster. But something had to be done inbetween.
>
>Thank you for your input, it helps to understand the problem more clearly, but unfortunately it still leaves some important questions open:
>-----------
>I did find anything about what to do when the TableUpdate function does not complete successfully when using CursorAdapters ?????
>--------------
>Some more details:
>All data sit on the SQL server, there is no DBC.
>As I am using VFP9 the data is retrieved from the server by using CursorAdapters via ODBC, which works as desired: The CAs retrieve the cursors, which have some computed fields as well, i.e. the downloaded cursors have more fields than the tables on the SQL server. Uploading by using TableUpdate works also quite well. Because the "computed" fields cannot be uploaded the necessary adjustments are done using the CA's properties (downloading - property CursorSchema with one entry for each downloaded or computed field, resp.; uploading - properties UpdatableFieldList and UpdateNameList contain the required entries for the fields, which should be uploaded and have corresponding fields in the table in the SQL server. Other properties settings: UpdateType = 1 (Update), UseCursorSchema = .T., UseTransactions = .T. etc.
>By using these CAs downloading and uploading works fine for quite some time without any complaints. So I am discussing on a mere theoretical ground.
>I am using CAs because they allow encapsulating the handling of the cursor into one object, the CA.
>For uploading the data I include the CAs into the said Transaction - End Transaction - Rollback. Up to now no problems either, but what happens if for some reasons one or more.
>What I learned from you comments so far is:
>1 - If the uploading fails, then "after" the Rollback the local cursors remain unchanged.
>2 - I have used views up to now only locally, not remote.
>3 - As far as CAs are concerned, the VFP 9 Help says:
>"Typically, the CursorAdapter object uses the transaction management functionality provided by the ADO or ODBC API's and Visual FoxPro closes transactions when the TableUpdate() function completes successfully...."
>----------
>I did find anything about what to do when the function does not complete successfully ?????
>----------
>The VFP help continues: "However, if you want to send transaction management commands directly to the backend, you can set the UseTransactions property of the CursorAdaptor object to False (.F.) and the CursorAdapter does not use transactions to send Insert, Update, or Delete commands....." Well this is not what I want to do, because I would like to use the transaction management functionality, if possible.
>So please help me on that functionality.
>
>Looking forward for your valuable comments.
>
>Hans
>
>
>>Hi,
>>
>>>that is, what I expected. But somehow I am confused about the Begin Transaction - End Transaction - Rollback squence. The VFP help say to End Transaction.
>>>"Ends the current transaction and saves any changes made to tables, table memo files, or index files included in a transaction."
>>>... saves to what?
>>
>>>
>>>Details: I have an SQL Server as back-end. Lets assume, I have 5 cursors with some changed data and I want to save the data to the SQL server with 5 TableUpdates(). When will these changes be "commited" finally, i.e. will be placed into the resp. tables within the SQL server? With each TableUpdate() or only after all reported "Could be done" (returned 5 times .T.), i.e. after the End Transaction?
>>>Unfortunately I did not find anything, which helps me to decide, what to do...
>>>
>>>Any help appreciated.
>>
>>ROLLBACK should leave everything in the state if was in at the point the BEGIN TRANSACTION was issued, i.e. any TABLEUPDATES() issued in the interim would be undone and any buffered changes would still exist. But, as Srdjan pointed out, with remote views you also need to manage the transaction on the server.
>>
>>HTH,
>>Viv