Hi Christian,

thank you for your advice - I will study that tomorrow.

I am glad I found another fan of CAs!

BTW: Do you know www.masfoxpro.com - would be nice to find your name there as well!

Gute Nacht & angenehme Träume!

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 && get ODBC connection handle
>&& each CA must use this one connection to participate in the transaction
>SQLSETPROP(lnCon,"Transactions",2) && enable manual transactions
>BEGIN TRANSACTION && start transaction for local cursors only
>DO CASE
> CASE !TABLEUPDATE(loCA1.Alias)
> CASE !TABLEUPDATE(loCA2.Alias)
> CASE !TABLEUPDATE(loCA3.Alias)
> OTHERWISE
>  lbSuccess = .T.
>ENDCASE
>
>IF lbSuccess
>  IF SQLCOMMIT(lnCon) != 1
>    && AERROR(laOdbcError) && handle error
>    ROLLBACK
>  ELSE
>    END TRANSACTION
>  ENDIF
>ELSE
>  AERROR(laOdbcError) && handle TABLEUPDATE error
>  SQLROLLBACK(lnCon) && rollback SQL Server transaction
>  ROLLBACK           && rollback local cursors
>ENDIF
>SQLSETPROP(lnCon,"Transactions",1) && reset transaction setting on connection
>

>
>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