FIX: Failed Sp_prepare Incorrectly Closes Transaction

Article translations Article translations
Article ID: 198265 - View products that this article applies to.
This article was previously published under Q198265
This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 53474 (SQLBUG_70)
Expand all | Collapse all


Failure to prepare a statement, either by means of ODBC or OLE DB, incorrectly results in the failure of the entire transaction. Potential causes for such a failure include syntax errors or incorrect object names in the statement. Subsequent operations that depend on the transaction being active, including attempts to commit the transaction, will fail.


SQL Server incorrectly closes the whole transaction after any error, rather than stopping execution of the statement only.


To work around this problem, execute the statement without first preparing it, using SQLExecDirect or ICommandText::Execute. An error during either of these operations will cause only the statement, rather than the whole the transaction, not to be processed. The application can then determine the appropriate response, such as ignoring the error and continuing with other statements, resubmitting the query without the problem, or rolling back the transaction.


Microsoft has confirmed this to be a problem in SQL Server 7.0. This problem has been corrected in U.S. Service Pack 1 for Microsoft SQL Server 7.0. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
232570INF: How to Obtain Service Pack 1 for Microsoft SQL Server 7.0 and Microsoft Data Engine (MSDE) 1.0
For more information, contact your primary support provider.


Attempts to commit or roll back the transaction after it has been prematurely closed may result in the following errors:
Msg 3902
The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.

Msg 3903
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.

You may also encounter other errors that are not obviously related. For example, non-static cursors are closed when a transaction is rolled back; thus, if the application had previously opened such a cursor as part of this transaction, it will be closed, and attempts to fetch from or close this cursor would result in various errors indicating that the cursor is not open.


Article ID: 198265 - Last Review: October 11, 2013 - Revision: 2.1
  • Microsoft SQL Server 7.0 Standard Edition
kbnosurvey kbarchive kbbug kbfix kbqfe KB198265

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from