Thanks!

>Yes.
>
>>Does @@trancount work with SQLServer 2000?
>>
>>
>>>It seems to me very unreliable. You can certainly send COMMIT with error trap to see if transaction still open, but I feel it's wrong approach. What is going to happen if you client just crashes?
>>>I would use remote view/cursor adapter and table buffering for this situation.
>>>
>>>>I agree, but in this case, a begin is sent as soon as a change is made to a field on a form. There is a grid displaying a small result set and they want all edits to be within one single transaction to roll them all back if necessary. That part is working fine. The code to rollback or commit is in the form's queryunload method so if the form is exited by the button or the X, it rollsback the transaction or commits it. A form property is set to true when the BEGIN TRANSACTION is sent to the server successfully when the first (whichever it is) field is edited. I just want to check after the form is closed (or before it is destroyed) to see if there is a transaction pending in a more reliable means communicating with SQL Server rather than using the form property.
>>>>
>>>>
>>>>
>>>>>>Connecting to SQLServer 2005, if a BEGIN TRANSACTION is sent to SQLServer, what is the safest way to determine if a ROLLBACK or COMMIT were or were not sent to end the transaction? If you send a COMMIT or ROLLBACK and no transaction is pending, you receive the SQL error...
>>>>>
>>>>>Imho, you shouldn't send them separately, i.e. you better call SP that contains both BEGIN and COMMIT.