|
I am using Sql Server 2005 I have a situation where I need the inserts of one table modification to be correlated with modifications in other tables. One approach we considered was using a temporary table to store the "correlation id" (in the example below, that would be http://msdn.microsoft.com/en-us/library/ms174979.aspx indicates that the local temporay table would be scoped to the current "database session". However, I am not clear on what "database session" is. It is important that the triggers all execute in the same transaction, and that if the transaction is rolled back, all the inserts created by the trigger are rolled back as well. What is a "database session" in this context and how does it relate to transactional isolation? (Or am I just setting myself up for a world of pain by trying to use triggers to do this?) For example:
(comments are locked)
|
|
First of all, this simply can be acheived with Secondly, all of your main concerns are answered in the same thread you have referred to
Following could be what you want. After such implementation, you will not be needing the insertions into History table through triggers. I must let you know that your current BEGIN TRANSACTION BEGIN TRY..CATCH structure is not in a proper shape.
Mar 07 '12 at 06:55 AM
robbin
Looks like a possibility, I'll have to spend some more time looking at it. Though I'm still not clear on what a "database session" exactly is.
Mar 07 '12 at 07:05 AM
user-470
Also, what is wrong with the BEGIN TRANSACTION BEGIN TRY..CATCH structure that I have? I thought it was pretty standard.
Mar 07 '12 at 07:06 AM
user-470
For temporary tables, the scope is limited to the session. A session is made when you connect to the sql server instance. As long as you are connected to the instance with the same session, you can call out that specific temp table. You can pass that temp tables to stored procedures and even triggers. I would not do the latter, as it could cause some bad performance and unwanted scenarios. But I do not understand why you need a temp table? Are you trying to create a temp table in the trigger? In that case you would not be able to call that temp table in the script. The scope of that temp table would end with the execution of the trigger. And somehow, If you still want the temp table, then add that temp table in the above script. Then you would be able to refer it in all the related triggers. The scope of the temp table would remain until you disconnect your session. Hope that clears the ambiguity. As far as BEGIN TRANSACTION... structure, if the statement is rolled back, the last COMMIT TRANSACTION would still be executed and will give the error. Moreover, you have to get the Error messages filled in the variables, before the ROLLBACK statement.
Mar 07 '12 at 07:48 AM
robbin
I believe the RAISERROR would stop the execution of the script before the COMMIT TRANSACTION was reached.
Mar 07 '12 at 04:40 PM
user-470
(comments are locked)
|

