>Thanks Aleksey,
>
>>However, the fix I am thinking of is to force rollback rather than do nothing or generate an error.
>
>I'm agree with this,
>but it can make VFP not compatible with MS SQL Server associated sessions.
>
>If i use sp_getbindtoken and sp_bindsession on two VFP connection
>( also on two different VFP process ),
>if SQLDISCONNECT() execute a implicit SQLROLLBACK(),
>i am not sure that the use of associate sessions always is corrected.
>
>Example:
>i implement a shared coherent job between two or more clients, in order to carry out a task more quickly.
>
>Every client execute:
>

>BEGIN TRAN
>perform the job
>COMMIT
>

>
>When 3 clients worked: => @@TRANCOUNT=3.
>

>Situation 1:
>Client 1 end correctly => SQLCOMMIT() => @@TRANCOUNT=2.
>Client 2 end correctly => SQLCOMMIT() => @@TRANCOUNT=1.
>Client 3 end correctly => SQLCOMMIT() => @@TRANCOUNT=0 => SQL Server COMMIT the job.
>
>Situation 2:
>Client 1 end correctly => SQLCOMMIT()    => @@TRANCOUNT=2.
>Client 2 end not correctly ( no action ) => @@TRANCOUNT=2.
>Client 3 end correctly => SQLCOMMIT()    => @@TRANCOUNT=1 => Disconnection => SQL Server ROLLBACK the job.
>
>Situation 3:
>Client 1 end correctly => SQLCOMMIT()    => @@TRANCOUNT=2.
>Client 2 end not correctly and SQLDISCONNECT() send a SQLROLLBACK() =>
>SQL Server rollback all, and Client 3 can go out of control.
>

>
>Hovewer, SQLDISCONNECT() can perform SQLROLLBACK() only is VFP control the
>status of the connection.
>
>Need a good analysis before make a choice.
>
>I suggest to add this sqlhandle property:
>

>* for default SQLDISCONNECT send SQLROLLBACK()
>=SQLSETPROPERTY(con,"AutoRollback",.T.)
>* choice of developer
>=SQLSETPROPERTY(con,"AutoRollback",.F.)
>* SQLDISCONNECT send nothing
>

>
>Fabio

Hi Fabio,

We will have to add setting like that default to COMMIT on disconnect for backward compatibility reasons, we don't want to break legacy applications. But, I believe "do nothing" shouldn't be an option because it may cause some undesired side effects during VFP shutdown. To prevent session to be affected by normal SQLDisconnect, client should configure connection to ROLLBACK on disconnect in case something goes wrong, bind connection, do what it should to do and then unbind connection.

Thanks,
Aleksey.