New answers tagged transaction
In Oracle BEGIN starts a PL/SQL block. In other words, after BEGIN you ought to provide a text of a program that is written in a procedural language that is somewhat different than SQL (although it bears some similarities). Your sqlplus had read everything but it was not yet parsing or executing anything, it was waiting for an END and a line containing only ...
Oracle's transactions are implicit in sqlplus you're already in one and don't have to start it. This means you can just do select ... update .. rollback ... select... if you do an exit without doing exit rollback it will commit on exit. begin is not necessary here.
AFAIK there is no way in TSQL to deal with this other than the way you currently are with XACT_ABORT. There are no structures that TSQL knows (or even cares about) as everything this deals with lives outside of TSQL. What is actually happening is called an "Attention" event which could range from a connection closing to an actual cancel (for example the ...
It depends on when the trigger fires during the transaction. The trigger itself is part of the transactional context you are currently in. This means that any changes you have already made in the transaction so far will be visible to the trigger. To take a simple example, consider this data model: CREATE TABLE Foo (F INT) CREATE TABLE Bar (B INT) INSERT ...
nvarchar(8) PK NOT NULL ... their PKs return null ... This cannot happen, under any condition. Therefore I must conclude that your 'simplified' repro has simplified things beyond the limit of what you understand. Please post the exact table definition (including all indexes) and the exact query you issue. Null is what comes back from the linq ...
If you're using READ UNCOMMITTED isolation level or the WITH (NOLOCK) in your queries, your queries can skip rows or see rows twice. Kendra Little explains it in more detail in her 30-minute webcast There's Something About Nolock.
It seem's that one viable way of solving this issue is using a table engine that does not support transactions. In this case changing the table engine of the log tables from InnoDB to MyISAM solved the problem.
I think your problem is simply having a BEFORE trigger - it fires before the row is inserted which cannot appear in the view yet. Change it to AFTER and (after considering Craig's suggestion) you are done.
Top 50 recent answers are included