Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Onamuji
Aged Yak Warrior
504 Posts |
 Posted - 2002-01-10 : 09:05:16
|
| For some reason a set of queries performed on an ASP page via ADO were running fine until yesterday we started recieving the error, cannot start another session on this transaction. It said because XACT_ABORT was not on. So I set it on and it fixed this, what the heck is this option? Is there something I should look for to not use this? Does this affect my transactions?Thanks!- Onamuji |
|
|
Nazim
A custom title
1408 Posts |
Posted - 2002-01-10 : 09:43:19
|
This is what BOL has to offer and its self Explanatory for a Master like you When SET XACT_ABORT is ON, if a Transact-SQL statement raises a run-time error, the entire transaction is terminated and rolled back. When OFF, only the Transact-SQL statement that raised the error is rolled back and transaction continues processing. Compile errors, such as syntax errors, are not affected by SET XACT_ABORT.It is recommended that XACT_ABORT be set ON when executing data modification statements against remote tables in an implicit or explicit transaction. For more information, see Distributed Queries and Distributed Transactions. The setting of SET XACT_ABORT is set at execute or run time and not at parse time.----------------------------Anything that Doesn't Kills you Makes you Stronger |
 |
|
|
Onamuji
Aged Yak Warrior
504 Posts |
Posted - 2002-01-10 : 10:06:27
|
| Thanks! 5 minutes after I posted I realized it was probably BOL ... I checked the wrong one yesterday confusing it for a ADO problem. Thanks anyhow! This solved a lot of problems :-) Since I am new to the distributed query scene, but I'm liking it.- Onamuji |
|
|
|
|
|
|
SET XACT_ABORT ON