Exception handling in Triggers.

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.
"ben brugman" <ben@.niethier.nl> wrote in message
news:%23VPXOAQkEHA.3724@.TK2MSFTNGP11.phx.gbl...
> 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 ?
Not just a constraint violation; ANY error will abort (and consequently
rollback) the entire batch.

> What if there was no transaction start ?
Every DML operation in SQL Server uses a transaction, even if you don't
explicitly request it.
So:
UPDATE Tbl
SET Val = 0
WHERE SomeCol = 1
will use a transaction. That way, if there are two rows where SomeCol =
1, and the first was successful but the second had an error, the entire
batch will roll back to the initial state.

> When sending several statements, it appears
> that all statements are rolled back. (Are handled
> as one transaction).
Do you have IMPLICIT_TRANSACTIONS turned on for your session?
This option causes SQL Server to treat multistatement batches as if they
were wrapped in a transaction. But it's not turned on by default in Query
Analyzer or any connection library that I know of...

Exception handling in Triggers.

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."ben brugman" <ben@.niethier.nl> wrote in message
news:%23VPXOAQkEHA.3724@.TK2MSFTNGP11.phx.gbl...
> 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 ?
Not just a constraint violation; ANY error will abort (and consequently
rollback) the entire batch.

> What if there was no transaction start ?
Every DML operation in SQL Server uses a transaction, even if you don't
explicitly request it.
So:
UPDATE Tbl
SET Val = 0
WHERE SomeCol = 1
will use a transaction. That way, if there are two rows where SomeCol =
1, and the first was successful but the second had an error, the entire
batch will roll back to the initial state.

> When sending several statements, it appears
> that all statements are rolled back. (Are handled
> as one transaction).
Do you have IMPLICIT_TRANSACTIONS turned on for your session?
This option causes SQL Server to treat multistatement batches as if they
were wrapped in a transaction. But it's not turned on by default in Query
Analyzer or any connection library that I know of...