>Aleksey ????
>
>It is very good you brought this up. I've double checked and it is actually not driver,
>
>but VFP forces transaction to be committed before connection is closed.
>
> This behavior goes back at least to VFP6 and most likely to the time when SPT was added to the product.
>
>But you have aks to me this:
>
>VFP never calls [set implicit_transactions on] and it never calls [IF @@TRANCOUNT > 0 COMMIT TRAN]. VFP doesn't target any specific backend. And as a good ODBC client it uses SetConnectOption(...,SQL_AUTOCOMMIT,..) and SQLTransact() functions to manage transactions. For VFP developers: SQLSETPROP(con,"Transactions",...) is mapped to SetConnectOption(...,SQL_AUTOCOMMIT,..), SQLCommit() is mapped to SQLTransact(...,....,SQL_COMMIT) and SQLRollback() is mapped When I say mapped, I mean that VFP forwards the call to ODBC and doesn't do anything else, ODBC driver decides what commands to call and when to call them.
>
>If connection is closed while there is in an active transaction,
>
>driver commits changes.
>
>
>I'm returned to the departure point, is VFP that executes the commit or the driver?
>
>
>Should the behavior be changed now?
>yes
>
>Not an easy question to answer.
>
>Easy
>If a developer use SQLSetProp(nConn, "Transactions", DB_MANUAL)
>and SQLDISCONNEC(nConn) for commit changes, it is a mistaken.
>
>Fabio
Hi Fabio,
I've looked what VFP documentation says about SQLDisconnect and it made the answer very easy.
Here is what VFP help says:
According to this, current behavior SQLDisconnect() behavior is a legitimate BUG and, I assume, that it is not likely anyone relied on it. However, the fix I am thinking of is to force rollback rather than do nothing or generate an error.
About backend specific commands for transaction management: I am still positive that VFP doesn't execute them and it delegates this work to ODBC driver.
Thanks,
Aleksey.
