The information in this article applies to:
SUMMARYThis article discusses what constitutes a implicit transaction in SQL Server. MORE INFORMATION
Users can explicitly delimit the boundaries of transactions with the BEGIN,
COMMIT, and ROLLBACK TRANSACTION commands. These user-defined transactions
are started with a BEGIN TRANSACTION command. All updates done from the
BEGIN TRANSACTION command to a subsequent COMMIT TRANSACTION or ROLLBACK
TRANSACTION are considered to be one transaction and are either all
successful or all rolled back as one unit.
In DB-Library (DB-Lib) applications a batch is terminated when the dbsqlexec() or dbsqlsend() function is called. The entire batch is sent to SQL Server, which first parses the batch and builds an execution plan for it, then executes the plan. If some error prevents SQL Server from compiling the execution plan, none of the commands in the batch are executed, and the user might think the entire batch was rolled back. Examples of this type of error include (but are not limited to) invalid names, syntax errors, or permissions errors. While it might appear the entire batch was rolled back, instead nothing in the batch was executed. If the execution plan is successfully built and SQL Server begins executing the plan, then the standard rule that each individual command is a distinct transaction (outside a user-defined transaction) applies. If a run time error occurs during the execution of one of the commands in the batch, any UPDATE commands already executed will have been committed. Examples of these types of errors include (but are not limited to) insufficient resource errors, trigger violations, and deadlocks. Additional query words: dblib Windows NT
Keywords : kbprg SSrvWinNT |
Last Reviewed: March 19, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |