mdissel wrote:
Otis wrote:
Inserts don't throw ORMConcurrencyExceptions as there's nothing for concurrency to check: they're new rows, so they're not UPDATING an existing row. That's what concurrency is all about: multiple updates / deletes on the same row. Inserts is a different matter in this: there's always a single insert.
Yes, but there's no exception raised at all.. I expected an exception even on an insert, because of the raiserror instruction in the trigger..
Hmm...
Well, all exceptions thrown by the ADO.NET provider are wrapped, so if it reaches .net code, it is wrapped. Perhaps the severity level you specified isn't enough? You should use a severity level of 11 or higher ('Handling Errors and messages in applications, sqlserver 2005 BOL')
Otis wrote:
btw, rollbacks of transactions inside the db could lead to 'zombie' transactions in .net: the ADO.NET transaction object doesn't get a signal from the db that the transaction has been rolledback.
raiserror is enough? rollback tran is not necessary?
Thanks
Marco
The transaction is also rolled back in .NET code. So if you roll back a transaction inside the trigger, raise an error which results in an exception, the transaction is also rolled back there, which leads to an exception if the transaction is already rolled back.
However, if the update/insert was a single statement and no transaction was necessary, the rollback is required. You can test this with @@TRANCOUNT. If it's 0, the trigger is executed inside an implicit transaction (insert /update statement's own transaction) and you should rollback. if it's > 0, a BEGIN TRANS has been called and you should NOT rollback
Still it's odd that there's no error reported...