SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Question of the Day for 17 Oct 2005


Question of the Day for 17 Oct 2005

Author
Message
Ninja's_RGR'us
Ninja's_RGR'us
One Orange Chip
One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)

Group: General Forum Members
Points: 28703 Visits: 9671
Yes... try opening a transaction and executing something that will violate a constraint. The whole operation will be rolled back.
fga100
fga100
SSC-Enthusiastic
SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)

Group: General Forum Members
Points: 145 Visits: 10
Please read my post. According to the text of the question, we aren't running in a transaction. No transaction = no rollback.



Ninja's_RGR'us
Ninja's_RGR'us
One Orange Chip
One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)

Group: General Forum Members
Points: 28703 Visits: 9671
That's what you have to learn in that question ::


CREATE TABLE dbo.A (PK int not null primary key clustered)
GO
CREATE TRIGGER dbo.trDemoA_IUD ON dbo.A
FOR INSERT, UPDATE, DELETE
AS
SET NOCOUNT ON
ROLLBACK TRANSACTION
RAISERROR ('Cannot allow any DML operation on table A', 13, 1)
SET NOCOUNT OFF
GO
INSERT INTO A (PK) VALUES (4)
GO
DROP TABLE dbo.A
GO

This transaction will rollback even if I didn't create the tran myself.
~pgerrits
~pgerrits
SSC Eights!
SSC Eights! (999 reputation)SSC Eights! (999 reputation)SSC Eights! (999 reputation)SSC Eights! (999 reputation)SSC Eights! (999 reputation)SSC Eights! (999 reputation)SSC Eights! (999 reputation)SSC Eights! (999 reputation)

Group: General Forum Members
Points: 999 Visits: 4

In regards to the discussion of pseduo coding this question and that fact that it might be a red hearing to give the information on no parent child relationship.

I belive that this is a great question, to those of us that have taken microsoft exams know, they are filed with questions worded such as these, they test you not only on your knowledge of the problem, but also on your ability to take the information given, discount what is not revelent to the issue and make your decision based on the facts given. Yes its a little hard to read and takes a minute to understand, but when faced with a issue in real life, no one is going to pseduo code the problem for you and take out what is not relevent.

The only answer of course is the correct answer given, complete rollback.

Also, Triggers are always run inside of a transaction by default, you do not have to explicity identifiy one.

my 2 cents





fga100
fga100
SSC-Enthusiastic
SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)

Group: General Forum Members
Points: 145 Visits: 10

There is no transaction, according to the question. You are coming into the trigger without being in the context of a transaction. In other words, there was no "begin transaction" executed anywhere before the trigger started.

No transaction = no rollback.





Ninja's_RGR'us
Ninja's_RGR'us
One Orange Chip
One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)

Group: General Forum Members
Points: 28703 Visits: 9671
Dude run my code, learn something and stop asking for free points.
Adam Machanic
Adam Machanic
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1535 Visits: 714
There is ALWAYS a transaction whenever any kind of data modification occurs. Each DML statement starts an implicit transaction. You can choose to enlist one or more DML statements in an explicit transaction (using BEGIN TRAN / ROLLBACK / COMMIT), but there is no way to turn off the implicit transaction. That's one of the many features in SQL Server that helps to ensure the ACID properties.

--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
fga100
fga100
SSC-Enthusiastic
SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)

Group: General Forum Members
Points: 145 Visits: 10

That's only true if you run in Implicit Transaction Mode (SET IMPLICIT_TRANSACTIONS ON).

Otherwise you have to execute a BEGIN TRAN to start a transaction.





Adam Machanic
Adam Machanic
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1535 Visits: 714
No, that's incorrect. Implicit transactions create an implicit multistatement transaction. But single statements still have their own implicit transactions. Take this batch, for instance:

INSERT Tbl VALUES ('w', 'x')
INSERT Tbl VALUES ('y', 'z')

Each of these inserts will start and end its own transaction (implicit -- because you are not explicitly starting a tran). EVERY DATA MODIFICATION USES A TRANSACTION. You cannot turn that off.

If you want to enlist both of these inserts in a single transaction (so that, e.g., if one fails the other can be rolled back with it), you have two choices:

BEGIN TRAN
-- do work
(COMMIT or ROLLBACK)

or:

SET IMPLICIT_TRANSACTIONS ON
-- do work
(COMMIT or ROLLBACK)


The difference between these is that if you use IMPLICIT_TRANSACTIONS, another multistatement tran starts automatically as soon as any data modification occurs. With BEGIN TRAN, you're controlling it, and you can let statements run using their own, atomic transactions.

Understanding how transactions work is extremely important when working with any DBMS. I highly recommend picking up Kalen Delaney's book, _Inside SQL Server 2000_, if any of this is new to you.

--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Peter Kryszak
Peter Kryszak
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1344 Visits: 3
faq100,

Try a multirow insert with values that violate a constraint on one or more columns on some of the rows.

With or without explicit or implicit transactions, no rows will be inserted.

Any row updates that don't violate constraints before or after the "bad" rows will not be committed to the database. The statement fails as a whole because it is atomic.

If you are hung up on the term "transaction" then we should talk about atomicity of statements rather than transactions. In the case of triggers, there are multiple statements being processed behind one statement and these must ensure the atomic nature of the original SQL statement.

As a reference, check out Delaney's Inside MS SQL Server 2000 page 305.

Maybe you should try this out yourself.



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search