Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 Delete Triggers

Author  Topic 

Stanley Tan
Starting Member

25 Posts

Posted - 2002-06-07 : 20:31:15
How do I make SQL Server delete triggers execute on a per row basis. In Oracle, you use FOR EACH ROW --> how do you do this in SQL Server?

For example, I have a delete statement that deletes multiple rows. The trigger should fire for each row deleted.

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-06-07 : 21:22:44
Oracle does not use a set-based approach in its triggers. In SQL Server, a trigger does not fire for each row deleted, it fires once per DELETE statement, and ALL rows that are affected by the DELETE are handled in one operation.

What specifically do you want to do on a row-by-row basis? Realize that in a relational database system, row operations are vastly more inefficient that treating the entire set as one object and processing it accordingly. This is NOT a shortcoming in SQL Server, although your previous experience with Oracle might make you think otherwise. In truth, Oracle is doing it the "wrong" way by doing row-by-row operations.

Edited by - robvolk on 06/07/2002 21:50:09
Go to Top of Page

Stanley Tan
Starting Member

25 Posts

Posted - 2002-06-08 : 06:13:32
Hmm... that makes a lot of sense. I guess I just need the number of rows deleted. @@ROWCOUNT has this, right? Is there anything I should watch out for when using @@ROWCOUNT?

Off topic, but what is the difference between @VARIABLE and @@VARIABLE?

Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-06-08 : 08:02:46
Yes, @@ROWCOUNT returns the number of rows affected by the LAST statement executed. If you need to get the rows deleted, check @@ROWCOUNT immediately after the DELETE statement, before you run another statement.

A @@ variable is a system variable, like @@ROWCOUNT, @@IDLE, @@SPID; you could think of them as functions, but technically they're not. A @ variable is defined by the user and can be named anything and can store anything. If you wanted to store the number of rows deleted, you can do this:

DECLARE @rowsDeleted int
DELETE FROM myTable
SET @rowsDeleted=@@ROWCOUNT


You don't need to do this in a trigger, just include it in the batch that deletes rows.

Go to Top of Page

LarsG
Constraint Violating Yak Guru

284 Posts

Posted - 2002-06-08 : 08:13:26
@@name is a global system maintained variable
@name is a user defined variable

ed:
Where is that refresh function when you need it.

Edited by - LarsG on 06/08/2002 08:14:26
Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-06-08 : 08:31:52
Dunno, mine's also broken

Go to Top of Page

simondeutsch
Aged Yak Warrior

547 Posts

Posted - 2002-06-10 : 22:49:11
Hmmm... Is this why my Delete triggers aren't working the way I thought?
If the trigger fires only once per statement, does it sort of call itself recursively for all rows? Else, what would happen if you try to SELECT s/t FROM Deleted? Does the Deleted table hold more than one row?

Sarah Berger MCSD
Go to Top of Page

byrmol
Shed Building SQL Farmer

1591 Posts

Posted - 2002-06-10 : 22:57:57
Sarah,

There is NO recursion...
It treats SETS not ROWS. A SET can contain 0, 1 or a billion rows...

The DELETED and INSERTED tables hold ALL rows affected...

DavidM

"SQL-3 is an abomination.."
Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-06-11 : 07:02:20
David is right, if you are writing your trigger code as if it will only handle single rows, it will not behave as you expect. If you write triggers to handle data as if it were a regular table in a SELECT statement, then they'll work correctly.

Go to Top of Page
   

- Advertisement -