Rollback not working. Any ideas?
-
I'm connecting to an SQL Server database, using BeginTransaction, and I've discovered that Rollback isn't working! The transactions are not rolled back. Reading through MSDN, I found this: To ensure that the .NET Framework Data Provider for SQL Server transaction management model performs correctly, avoid using other transaction management models, such as the one provided by SQL Server. Now, what does that mean? How do I disable SQL Server's transaction management model? Or is this not the problem. Thanks! Marc My website
Latest Articles: Object Comparer String Helpers -
I'm connecting to an SQL Server database, using BeginTransaction, and I've discovered that Rollback isn't working! The transactions are not rolled back. Reading through MSDN, I found this: To ensure that the .NET Framework Data Provider for SQL Server transaction management model performs correctly, avoid using other transaction management models, such as the one provided by SQL Server. Now, what does that mean? How do I disable SQL Server's transaction management model? Or is this not the problem. Thanks! Marc My website
Latest Articles: Object Comparer String Helpers -
I'm connecting to an SQL Server database, using BeginTransaction, and I've discovered that Rollback isn't working! The transactions are not rolled back. Reading through MSDN, I found this: To ensure that the .NET Framework Data Provider for SQL Server transaction management model performs correctly, avoid using other transaction management models, such as the one provided by SQL Server. Now, what does that mean? How do I disable SQL Server's transaction management model? Or is this not the problem. Thanks! Marc My website
Latest Articles: Object Comparer String HelpersI believe that what is meant is that you should not: 1. issue "set implicit_transactions on" at any point in your code (sql statements) as this turns on autocommit and defeats the possibility of rollback 2. Use transactions inside stored procedures or SQL statements, since commits inside the sproc/SQL will break rollback of the containing (external .NET) transactions. Basically you have three choices: 1. do all transactions with the API. 2. Use autocommit and forget transactions (bad idea most of the time). 3. do transactions in stored procedures/SQL and not the API. any mixing of these will be broken in strange ways. this quote from books online is also pertinent: If a severe error prevents the successful completion of a transaction, SQL Server automatically rolls back the transaction and frees all resources held by the transaction. If the client's network connection to SQL Server is broken, any outstanding transactions for the connection are rolled back when the network notifies SQL Server of the break. If the client application fails or if the client computer goes down or is restarted, this also breaks the connection, and SQL Server rolls back any outstanding connections when the network notifies it of the break. If the client logs off the application, any outstanding transactions are rolled back. If a run-time statement error (such as a constraint violation) occurs in a batch, the default behavior in SQL Server is to roll back only the statement that generated the error. You can change this behavior using the SET XACT_ABORT statement. After SET XACT_ABORT ON is executed, any run-time statement error causes an automatic rollback of the current transaction. Compile errors, such as syntax errors, are not affected by SET XACT_ABORT. [Edit] modified to clarify that Transactions inside SQL statements should not be mixed either Absolute faith corrupts as absolutely as absolute power Eric Hoffer All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke
-
The MSDN text means "dont send BEGIN TRAN commands to the server yourself.". Have you assigned the transaction back to the command, before using it? There's a sample on Rollback.
Morten Rasmussen wrote: The MSDN text means "dont send BEGIN TRAN commands to the server yourself.". OK. Not doing that. Morten Rasmussen wrote: Have you assigned the transaction back to the command, before using it? Yes. I'm looking at the Rollback example in MSDN, and I'm not doing things different (so says me now, but I'm sure there's something goofy going on). I did notice, to my horror, that I was using the same SqlConnection over and over. Gads, and this is for a server application! Marc My website
Latest Articles: Object Comparer String Helpers -
I believe that what is meant is that you should not: 1. issue "set implicit_transactions on" at any point in your code (sql statements) as this turns on autocommit and defeats the possibility of rollback 2. Use transactions inside stored procedures or SQL statements, since commits inside the sproc/SQL will break rollback of the containing (external .NET) transactions. Basically you have three choices: 1. do all transactions with the API. 2. Use autocommit and forget transactions (bad idea most of the time). 3. do transactions in stored procedures/SQL and not the API. any mixing of these will be broken in strange ways. this quote from books online is also pertinent: If a severe error prevents the successful completion of a transaction, SQL Server automatically rolls back the transaction and frees all resources held by the transaction. If the client's network connection to SQL Server is broken, any outstanding transactions for the connection are rolled back when the network notifies SQL Server of the break. If the client application fails or if the client computer goes down or is restarted, this also breaks the connection, and SQL Server rolls back any outstanding connections when the network notifies it of the break. If the client logs off the application, any outstanding transactions are rolled back. If a run-time statement error (such as a constraint violation) occurs in a batch, the default behavior in SQL Server is to roll back only the statement that generated the error. You can change this behavior using the SET XACT_ABORT statement. After SET XACT_ABORT ON is executed, any run-time statement error causes an automatic rollback of the current transaction. Compile errors, such as syntax errors, are not affected by SET XACT_ABORT. [Edit] modified to clarify that Transactions inside SQL statements should not be mixed either Absolute faith corrupts as absolutely as absolute power Eric Hoffer All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke
If a run-time statement error (such as a constraint violation) occurs in a batch, the default behavior in SQL Server is to roll back only the statement that generated the error. Hmmm. Even if a BeginTransaction (via ADO.NET) was called before the batch commands were issued? Marc My website
Latest Articles: Object Comparer String Helpers -
If a run-time statement error (such as a constraint violation) occurs in a batch, the default behavior in SQL Server is to roll back only the statement that generated the error. Hmmm. Even if a BeginTransaction (via ADO.NET) was called before the batch commands were issued? Marc My website
Latest Articles: Object Comparer String HelpersYes. but, if you issue a "SET XACT_ABORT ON" the behavior is achanged sot the entire transaction is rolled back (by the rollback statement). See SET XACT_ABORT in the BOL for an example Absolute faith corrupts as absolutely as absolute power Eric Hoffer All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke
-
I believe that what is meant is that you should not: 1. issue "set implicit_transactions on" at any point in your code (sql statements) as this turns on autocommit and defeats the possibility of rollback 2. Use transactions inside stored procedures or SQL statements, since commits inside the sproc/SQL will break rollback of the containing (external .NET) transactions. Basically you have three choices: 1. do all transactions with the API. 2. Use autocommit and forget transactions (bad idea most of the time). 3. do transactions in stored procedures/SQL and not the API. any mixing of these will be broken in strange ways. this quote from books online is also pertinent: If a severe error prevents the successful completion of a transaction, SQL Server automatically rolls back the transaction and frees all resources held by the transaction. If the client's network connection to SQL Server is broken, any outstanding transactions for the connection are rolled back when the network notifies SQL Server of the break. If the client application fails or if the client computer goes down or is restarted, this also breaks the connection, and SQL Server rolls back any outstanding connections when the network notifies it of the break. If the client logs off the application, any outstanding transactions are rolled back. If a run-time statement error (such as a constraint violation) occurs in a batch, the default behavior in SQL Server is to roll back only the statement that generated the error. You can change this behavior using the SET XACT_ABORT statement. After SET XACT_ABORT ON is executed, any run-time statement error causes an automatic rollback of the current transaction. Compile errors, such as syntax errors, are not affected by SET XACT_ABORT. [Edit] modified to clarify that Transactions inside SQL statements should not be mixed either Absolute faith corrupts as absolutely as absolute power Eric Hoffer All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke
BTW, that is EXACTLY the problem! Except its not a constraint violation, but a "Cannot insert the value NULL into column..." error. [edit]erm, ok, that is a constraint violation. What am I thinking![/edit] Thank you very much! Now, erm...how does one set this programatically in ADO.NET? Marc My website
Latest Articles: Object Comparer String Helpers -
BTW, that is EXACTLY the problem! Except its not a constraint violation, but a "Cannot insert the value NULL into column..." error. [edit]erm, ok, that is a constraint violation. What am I thinking![/edit] Thank you very much! Now, erm...how does one set this programatically in ADO.NET? Marc My website
Latest Articles: Object Comparer String HelperssqlCommand.ExecuteNonQuery() whith "SET XACT_ABORT ON" as the SQL text should work. Not sure if the setting persists beyond the life of the connection, but I wouldn't plan on it. Absolute faith corrupts as absolutely as absolute power Eric Hoffer All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke
-
sqlCommand.ExecuteNonQuery() whith "SET XACT_ABORT ON" as the SQL text should work. Not sure if the setting persists beyond the life of the connection, but I wouldn't plan on it. Absolute faith corrupts as absolutely as absolute power Eric Hoffer All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke
Rob Graham wrote: sqlCommand.ExecuteNonQuery() whith "SET XACT_ABORT ON" as the SQL text should work. Tried that. It doesn't seem to. Works fine in Query Analyzer, just not running it from code. Hmmm... Marc My website
Latest Articles: Object Comparer String Helpers -
Rob Graham wrote: sqlCommand.ExecuteNonQuery() whith "SET XACT_ABORT ON" as the SQL text should work. Tried that. It doesn't seem to. Works fine in Query Analyzer, just not running it from code. Hmmm... Marc My website
Latest Articles: Object Comparer String HelpersPossibly you need "Enlist = true" in your connection string. Connection pooling may be messing with you... Also, you would need to "SET XACT_ABORT ON" before beginning the transaction. Absolute faith corrupts as absolutely as absolute power Eric Hoffer All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke
-
Possibly you need "Enlist = true" in your connection string. Connection pooling may be messing with you... Also, you would need to "SET XACT_ABORT ON" before beginning the transaction. Absolute faith corrupts as absolutely as absolute power Eric Hoffer All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke
Hi Rob, OK, it's probably working. I just put debug statements around the open/close/commit/rollback code, and it's committing the transaction when it shouldn't. So now it's my bug! Thank you very much for your help. I'd never have found this otherwise! Marc My website
Latest Articles: Object Comparer String Helpers -
Hi Rob, OK, it's probably working. I just put debug statements around the open/close/commit/rollback code, and it's committing the transaction when it shouldn't. So now it's my bug! Thank you very much for your help. I'd never have found this otherwise! Marc My website
Latest Articles: Object Comparer String HelpersHere is an example of transactional error handling that might help you out. You can use this in a stored procedure, which is the only way you should update a database anyway.
Declare @intErrorCode int select @intErrorCode = @@Error begin transaction If @intErrorCode = 0 begin -- insert SQL Statement set @intErrorCode = @@Error end If @intErrorCode = 0 begin -- insert another SQL Statement set @intErrorCode = @@Error end IF @Error = 0 commit transaction else rollback transaction return @Error"People who never make mistakes, never do anything." My blog http://toddsnotsoamazinglife.blogspot.com/ -
Here is an example of transactional error handling that might help you out. You can use this in a stored procedure, which is the only way you should update a database anyway.
Declare @intErrorCode int select @intErrorCode = @@Error begin transaction If @intErrorCode = 0 begin -- insert SQL Statement set @intErrorCode = @@Error end If @intErrorCode = 0 begin -- insert another SQL Statement set @intErrorCode = @@Error end IF @Error = 0 commit transaction else rollback transaction return @Error"People who never make mistakes, never do anything." My blog http://toddsnotsoamazinglife.blogspot.com/Thanks for the code snippet. ToddHileHoffer wrote: You can use this in a stored procedure, which is the only way you should update a database anyway. Why? BTW, in our application, the SQL is being generated dynamically from the schema information and the dirty fields. So SP's are pretty much out of the question. Marc My website
Latest Articles: Object Comparer String Helpers -
Thanks for the code snippet. ToddHileHoffer wrote: You can use this in a stored procedure, which is the only way you should update a database anyway. Why? BTW, in our application, the SQL is being generated dynamically from the schema information and the dirty fields. So SP's are pretty much out of the question. Marc My website
Latest Articles: Object Comparer String HelpersThere are three reasons only to use stored procs. #1 Security. You can grant users the ability to update records without having permissions to the table. It prevents users from connecting to your database from say access to update the tables. #2 Prevents SQL Injection attacks. #3 Performance is improved because the queries' execution plans are cached on the server. If you have to write out your sql commands because you are dynamically generating sql statements then so be it, but that sounds hairy to me. "People who never make mistakes, never do anything." My blog http://toddsnotsoamazinglife.blogspot.com/
-
There are three reasons only to use stored procs. #1 Security. You can grant users the ability to update records without having permissions to the table. It prevents users from connecting to your database from say access to update the tables. #2 Prevents SQL Injection attacks. #3 Performance is improved because the queries' execution plans are cached on the server. If you have to write out your sql commands because you are dynamically generating sql statements then so be it, but that sounds hairy to me. "People who never make mistakes, never do anything." My blog http://toddsnotsoamazinglife.blogspot.com/
ToddHileHoffer wrote: #1 Security. You can grant users the ability to update records without having permissions to the table. It prevents users from connecting to your database from say access to update the tables. In our system, the user doesn't have direct access to the database. All activity between the client and the server (not the DB server, but the application server) is secured, and only the application server on the remote machine has access to the DB. ToddHileHoffer wrote: #2 Prevents SQL Injection attacks. My understanding is that SQL injection attacks can be prevented by using parameters. ToddHileHoffer wrote: #3 Performance is improved because the queries' execution plans are cached on the server. My understanding is that SQL Server caches execution plans, regardless of whether they're from SP's or not. ToddHileHoffer wrote: If you have to write out your sql commands because you are dynamically generating sql statements then so be it, but that sounds hairy to me. Not at all. It's quite robust. :) Marc My website
Latest Articles: Object Comparer String Helpers