Re: Exception handling in Triggers.
From: ben brugman (ben_at_niethier.nl)
Date: 09/07/04
- Next message: Brian Moran: "Re: Select * in a View"
- Previous message: Brian Moran: "Re: Query Performance"
- In reply to: Peter The Spate: "Exception handling in Triggers."
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 7 Sep 2004 15:32:52 +0200
My email is
stbraslenscap@lenscaphiscom.nl
(Both lenscaps should be removed).
I tried to reply to your mail, but that bounced,
so now in the thread.
thanks in advance,
ben brugman
"Peter The Spate" <anonymous@discussions.microsoft.com> wrote in message
news:4ff601c49104$6e437d70$a301280a@phx.gbl...
> If we can get away from the trigger for a second.
>
> One of the least documented aspects on how transactions
> work are to do with the process id that its running from.
> So if you open up QA do transaction mock statement, open
> up another window in QA and do rollback you will get an
> error, why, becasue the process in the second window is
> different to the first.
>
> The reason why this is important is that a rollback as you
> found out will effect EVERY transaction in that process
> even though it maybe nested. Try this yourself, you will
> get some very interesting answers.
>
> So to get back to your question.
>
> SQL Server will automatically rollback transactions if the
> error is serious enough.
>
> If there is no transaction then there will be no
> transaction count, there is a handy little global variable
> called @@TRANCOUNT you may want to look at. So if that is
> set to anything but a 0 it will automatically rollback the
> transaction irrespective on whether it is done in trigger
> or something else.
>
> From application programs then it depends on the error. If
> you had a connection object and you application (not SQL)
> failed then it would be up to your application to repair
> the DB by sending it up a rollback.
>
> If you application using the same connection as the begin
> transaction sent some SQL that caused an error then yes it
> would automatically roll back.
>
> Anyway that it. I sugest you have a play on QA.
>
> If you have any questions then don't hesitate to email me
> on peternolan67REMOVETHIS@hotmail.com (though I am a bit
> busy tonight)
>
> Peter
>
> "You can always count on Americans to do the right thing -
> after they've tried everything else."
> Winston Churchill
>
>
>
>
>
> >-----Original Message-----
> >Can anybody point me to a good text about
> >exception handling in triggers (errors and rollbacks) ?
> >
> >From 'Inside' :
> >ROLLBACK (because of a fatal error or an
> >explicit ROLLBACK command), the entire batch is aborted.
> >
> >
> >As I read this :
> >From within a trigger any FK or relational constraint
> >violation results in a fatal error aborting the complete
> >batch (and complete transaction).
> >Is this correct ?
> >
> >What if there was no transaction start ?
> >In the QA, does the QA supply a transaction
> >(increase the transaction count) if no transaction
> >was started ?
> >When sending several statements, it appears
> >that all statements are rolled back. (Are handled
> >as one transaction).
> >Does something similar happen when doing
> >similar statements from application programs ?
> >
> >Thanks for your attention,
> >
> >ben brugman.
> >
> >
> >.
> >
- Next message: Brian Moran: "Re: Select * in a View"
- Previous message: Brian Moran: "Re: Query Performance"
- In reply to: Peter The Spate: "Exception handling in Triggers."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|