Hi Christian,
I beg you pardon: I am very sorry, that I had to give the three points ("solution") to Bernard, but he really opened my eyes on the real problem to be solved.
The code snippets, which you have been sending to me, provide exactly the same solution as Bernard's. But I belong to those people, who really have to know, why something has to be done, before they do (and believe) it.
Sorry, but I can give the three points to only one message. In spite of that: Many thanks for your efforts!!
Have a nice weekend!
Hans
>Hello,
>
>"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."
>
>this is exactly what you need, combined with "local" (FoxPro) transaction.
>
>If you set "UseTransactions" to .T. each INSERT,UPDATE,DELETE command send from a CursorAdapter is wrapped in it's own transaction.
>You want to update several CursorAdapter's in ONE transaction, correct?
>Then you have to handle transactions manually -> set "UseTransaction" to .F.
>on each CursorAdapter
>
>some pseudo code to show the structure:
>
>
>LOCAL lnCon, lbSuccess
>lbSuccess = .F.
>lnCon = loCA1.DataSource
>
>SQLSETPROP(lnCon,"Transactions",2)
>BEGIN TRANSACTION
>DO CASE
> CASE !TABLEUPDATE(loCA1.Alias)
> CASE !TABLEUPDATE(loCA2.Alias)
> CASE !TABLEUPDATE(loCA3.Alias)
> OTHERWISE
> lbSuccess = .T.
>ENDCASE
>
>IF lbSuccess
> IF SQLCOMMIT(lnCon) != 1
>
> ROLLBACK
> ELSE
> END TRANSACTION
> ENDIF
>ELSE
> AERROR(laOdbcError)
> SQLROLLBACK(lnCon)
> ROLLBACK
>ENDIF
>SQLSETPROP(lnCon,"Transactions",1)
>
>
>We're using CA's exclusivly in our app.
>Building base cursoradapter's for FoxPro data, and then subclasses for different SQL backends (if it's pure ANSI SQL the only thing we have to set in the subclass is "DataSourceType" to "ODBC"). Works really good. With remote views the app wouldn't have been possible since we have several m-n tables where we sometimes need to send UPDATE SQL commands from inserted rows, which is impossible with remote views, but with Cursoradapter's you can build whatever SQL commands you want in the BeforeInsert/BeforeUpdate/BeforeDelete events, very flexible.
>They beat remote views in every aspect IMHO.
>
>Regards
>Christian