Do you mean that base classes contain SQL-related codes (e.g. mytextbox interactivechange sends BEGIN TRAN to SQL Server)? It sounds like a bad design, really.

>Yes and I did not write it. I am just fixing what I can (as I find problems). Changing that would involve a change to the base classes... Don't even start... :o)
>
>
>
>>Hi Tracy,
>>
>>Sounds to me like a dangerous approach. Why you can not send all updates as one batch within a transaction? Are you saying you're openning a transaction as soon as one field change is made?
>>
>>Or did I misunderstand?
>>
>>>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.