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.