Transactions

for RuBoard

When a user transaction is not active, a trigger and the DML operation that fired it are considered a single transaction. This holds for any stored procedures or UDFs the trigger callseverything runs from within the same transaction.

When a trigger generates a fatal error or executes ROLLBACK TRANSACTION, the currently active transaction is rolled back and the current command batch is terminated . If this transaction is a user transaction, all changes made in that transaction are discarded. If it is the default transaction that's created anytime a data modification occurs, only the changes made by that one operation are lost.

For INSERT operations, the inserted logical table lists the rows being appended to the table. For DELETE operations, the deleted table lists the rows about to be removed from the table. For UPDATE operations, the deleted table lists the old version of the rows about to be updated, and the inserted table lists the new version. You can query these tables to allow or prevent database modifications based on the columns or data the operations are attempting to modify. Rolling back the current transaction is normally the way a trigger aborts because SQL Server's Transact -SQL doesn't support a ROLLBACK TRIGGER command (   la Sybase). Note that you can't modify these logical tables; they're for inspection only. If you need to use a trigger to alter the data changes about to be applied to a table before they're actually applied, use an INSTEAD OF trigger.

Minimally logged operations (operations that do not generate row modification log records) do not fire triggers. So, for example, even though TRUN-CATE TABLE deletes all the rows in a table, these row deletions aren't logged individually and therefore do not fire any delete triggers that may have been defined for the table.

for RuBoard