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