Hi Grigore,

1) VFP does not call [IF @@TRANCOUNT>0 COMMIT TRAN]. Please, refer to message #820638 for more information.

2) My example shows that CursorAdapter doesn't commit transaction if connection is in manual transaction mode (this what you should be using for multisatement/multitable transaction). More over, the transaction is still active after TABLEUPDATE. It is still possible to rollback the changes made by TABLEUPDATE function by executing SQLRollback. If you are not able to see this, there is nothing more I can do to help.

The mistake you've made in you application is the fact that you are sending BEGIN TRANSACTION to the server instead of putting connection into manual transaction mode. If you send BEGIN TRANSACTION to the server, you should have a good understanding of how things work, what the consequences are, what are the possible issues and how to avoid them. Obviously, you didn't have that good understanding and yet decided to neglect functionality provided by VFP SPT API to manage transaction in a safe way. Good thing is that now you know more than before, it should be easy to fix the code.

Thanks.
Aleksey.



>Hello, Aleksey
>
>I know my english is not very good and maybe this is the cause whe are speaking about two different things. In this message I'll try to put the whole story in other words.
>
>About the example you've posted: I am 100 percent positive that's the way the things are going. However, I staded somewehere something about the RV, and I'll quote myself:
>
>""IF @@TRANCOUNT>0 COMMIT TRAN" (I've seen that double-clicking the process in Enterprise Manager and that thingie shows the last command issued. Well... I don't have such command in my code. So it must be the CursorAdapter. I couldn't find any setting to make it stop that. There is no such behaviour in RV, with automatic transactions."
>
>I wanted to say the RV does close with commit tran only their own transaction, and they do not interfere with any other.
>
>To be more specific:
>If, suppose, I have to do a multitableupdate and I need to be sure all the tables are updated or none of them, then the implicit transaction doesn't help at all, because I need to enclose all the updates in one single transaction. All SQL servers supports nested transactions, so it seems logical to begin a transaction, do the updates (and at this point it doesn't matter if the autocommit is 1 or not - if it isn't, I'll issue the sqlcommit for every update).
>
>At the end of updates, I have to be able to commit the "big" transaction or rollback it. Well... with remote views this is absolutely possible - at the end of the updates I still have the "big" transaction.
>
>
>However, CA do not behave this way. I start the "big" transaction, and, if the SQLGETPROP(conn,"Transactions") = 1, the first CA closes it, no matter what. So: at the end of first update, I don't have the enclosing transaction anymore - it was commited by the CA. In this case, if one of the other updates fail, the first one is commited and it's too late to do something about it.
>
>The code you've posted to me is correct, I know that, but it shows only one update. On a two tables, it's true, but one single update. Try to simulate two consecutive updates, nested in a single transaction and if the second one fails, try to get the first table back as it was. That's it - rollback the nesting transaction. Fabio pointed the same issue in his message. The nesting transaction doesn't exist anymore, rollback can't be done, and the whole update was made just partially.
>
>Remote views do not behave this way. CA has a bug there. It does an autocommit by itself on a transaction which doesn't belong to it - that's it - the nesting transaction.
>
>
>I am sorry - I don't know how to say that more clear, using my english. I really hope you'll understand what I try to say here.
>
>And now follows the question:
>
>Is there a way to do:
>
>Tableupdate(table1)
>if failed
>rollback
>endif
>tableupdate(table2)
>if failed
>rollback
>tableupdate(table3)
>if failed
>rollback
>
>commit
>
>and to be sure the updates are done: 3 or none?
>
>Thank you.
>
>P.s. I appologize for my mood yesterday. Your remark about the help made me .... well.... somehow angry, because I did read the help. Managing data with cursoradapters has 1.5 printed pages. For a revolutionary component (as I still think CursorAdapter is) 1.5 pages is way too little.