Visual Studio and .NET Framework Home
TransactionScope timeout issue with SqlConnection and LTM (some operations are not rolled back)
3/29/2007 2:50:45 PM
User(s) can reproduce this bug
using (TransactionScope ts = new TransactionScope())
//Operation1 on connection
//Timeout occurs here
//Operation2 on connection
Operation1 is rolled back
Operation2 is not rolled back
.NET Framework 2.0
Operating System Language
Steps to Reproduce
using (TransactionScope ts = new TransactionScope(TransactionScopeOption.
using (SqlConnection connection = new SqlConnection(Properties.Settings.
SqlCommand cmd1 = new SqlCommand("INSERT INTO MyTable VALUES(1)",
SqlCommand cmd2 = new SqlCommand("INSERT INTO MyTable VALUES(2)",
SqlCommand cmd3 = new SqlCommand("SELECT COUNT(*) FROM MyTable", new
int count = (int)cmd3.ExecuteScalar();
Debug.Assert(count == 0, "Invalid value");
Execute* on SqlConnection when transaction is aborted executes operation without transaction
Execute* on SqlConnection when transaction is aborted should throw exception.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 8/20/2010 at 11:37 AM
Thanks for reporting this issue. It is now fixed in .Net 4.0, so instead of executing in AutoCommit mode, Operation2 will now throw the exception “System.InvalidOperationException: The transaction associated with the current connection has completed but has not been disposed. The transaction must be disposed before the connection can be used to execute SQL statements.”
You are correct that EnlistTransaction(null) with Explicit Unbind did not work as documented. This has also been fixed in .Net 4.0.
Software Development Engineer in Test
ADO.NET Managed Providers and DataSet Team
Mark A. Nicholson
on 7/28/2009 at 12:21 AM
The following statement is INCORRECT: "Explicit Unbinding is the new behavior. With this behavior, the connection remains bound to the transaction until it is closed or an explicit Enlist(null) call is made."
You cannot unbind a SQL connection from an enlisted transaction using SqlConnection.EnlistTransaction(null); -- EVER! Once the SqlConnection is enlisted in a transaction, it can only be unbound from the transaction under the following circumstances:
1. "TransactionBinding = Explicit Unbind" was specified in the connection string -- when SqlConnection is closed (or disposed).
2. "TransactionBinding = Implict Unbind" was specified in the connection string -- when the transaction ends (is committed, is aborted or times-out).
Any attempt to call SqlConnection.EnlistTransaction(null); will result in an InvalidOperationException: "Connection currently has transaction enlisted. Finish current transaction and retry."
on 8/17/2007 at 3:09 PM
This problem existed in Whidbey as well, and is an underlying design mis-match between System.Transactions and ADO.Net data providers. A option for new behavior has been added for the Orcas release.
The option: "Transaction Binding" keyword has been added as a valid SqlClient connection string option. Possible values are "Implicit Unbind" and "Explicit Unbind". e.g. ";Transaction Binding=Explicit Unbinding"
Implicit Unbinding is the default value if the keyword is not present. It is also the v2.0 behavior. With this behavior, the connection switches to auto-commit mode as soon as the transaction completes, which happens on a background thread during transaction timeout in the associated scenario. Subsequent executions on the connection are NOT associated with the transaction, and will commit or rollback separately.
Explicit Unbinding is the new behavior. With this behavior, the connection remains bound to the transaction until it is closed or an explicit Enlist(null) call is made. At at the start of each execute, if the transaction at System.Transactions.Transaction.Current is not the transaction bound to the connection, or if that transaction is not active, an exception will be thrown.
on 5/11/2007 at 4:57 PM
Thank you for reporting this issue. We are currently investigating this issue and developing a fix for this. As we know more we will update this report and confirm the fix.
Program Manager ADO.NET
on 3/30/2007 at 1:18 AM
Thanks for your feedback. We have reproduced this bug, and we are sending this bug to the appropriate group within the Visual Studio Product Team for triage and resolution. Thank you, Visual Studio Product Team.
on 3/29/2007 at 6:34 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com). Thank you, Visual Studio Product Team.
to post a workaround.
Please enter a workaround.
© 2013 Microsoft