By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,078 Members | 1,846 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,078 IT Pros & Developers. It's quick & easy.

Trigger problem no rowlevel support, please help!

P: n/a
Hello everybody.

Unfortunately I am pretty new to sql-server 2000
I need some help with a Trigger I created. I created a trigger witch
takes the id of the affected row and does a update on a other table
with that ID.
The trigger works fine with one affected row. But when there are more
then one rows affected, i get an error.
I found out that SQL-server does not support row-level triggers.
I should probable make my own cursor and itterate through the deleted
table. but i don't know how to do that. since i'm new to sql-server
2000

What I want is to itterate through the deleted table, just like the
ORACLE FORE EACH ROW.
retrieving the ID's and using them to update the CHECKED table.

Is there anybody who has encountered the same problem and has a
workaround for it?

I would really appreciate some help with this.

CREATE TRIGGER TR_Customers_CHECKED_Update ON Customers FOR UPDATE
AS
Begin
DECLARE @CUSTID bigint
SET @CUSTID = (SELECT CustomerID FROM Deleted)
update CHECKED set approved = 'NO' where CHECKED.CustomerID = @CUSTID;
end

Feb 20 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
SUKRU wrote:
Hello everybody.

Unfortunately I am pretty new to sql-server 2000
I need some help with a Trigger I created. I created a trigger witch
takes the id of the affected row and does a update on a other table
with that ID.
The trigger works fine with one affected row. But when there are more
then one rows affected, i get an error.
I found out that SQL-server does not support row-level triggers.
I should probable make my own cursor and itterate through the deleted
table. but i don't know how to do that. since i'm new to sql-server
2000

What I want is to itterate through the deleted table, just like the
ORACLE FORE EACH ROW.
retrieving the ID's and using them to update the CHECKED table.

Is there anybody who has encountered the same problem and has a
workaround for it?

I would really appreciate some help with this.

CREATE TRIGGER TR_Customers_CHECKED_Update ON Customers FOR UPDATE
AS
Begin
DECLARE @CUSTID bigint
SET @CUSTID = (SELECT CustomerID FROM Deleted)
update CHECKED set approved = 'NO' where CHECKED.CustomerID = @CUSTID;
end


Workaround for what? You don't need to do it for each row. Updates are
set based so triggers should be too. Always remember to account for
multiple row updates in troiggers. Do not use cursors in triggers.

BTW are you sure this is intended for an UPDATE trigger? The logic
looks more appropriate for a DELETE to me.

Try:

CREATE TRIGGER tr_customers_checked_update
ON customers FOR UPDATE
AS
BEGIN

UPDATE checked
SET approved = 'NO'
WHERE EXISTS
(SELECT *
FROM deleted
WHERE customerid = checked.customerid);

END

GO

(untested)

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/m...S,SQL.90).aspx
--

Feb 20 '06 #2

P: n/a
Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, data types, etc. in
your schema are. Sample data is also a good idea, along with clear
specifications.

Your design sounds flawed. You have a customer_id which has a huge
size, and no way to validate it (check digit, anything??) Next, we
seldom use binary flags in SQL; instead we have a history with (start,
finish, status) triplets and/or an encodeing scheme for the status.

When I see a table named "CHECKED", I get scared. That is a status,
not an entity or relationship!! It means that you have split an
attribute out of an entity and made it into a separate table. If you
had a "MalePersonnel" and a "FemalePersonnel", you see the flaw of a
split on "sex" immediately.

Knowing that uppercase names are almost 10 times more often mis-read or
mis-typed, why did you use them? We had no choice in the days of
punchcards. In fact, you whoel design seems to be a punch card system
done in SQL.

You need to learn BASIC RDBMS, and how to use VIEWs.

Feb 20 '06 #3

P: n/a
Hello Celko,

Thanks for the reply!
Your right I'm a beginner, but the example above is ficticious!
In fact there is no checked table! I made that up. I choose the checked
name just for practice sake. The original tables are in Dutch, i
wouldn't want to bother you with Dutch ;).

Further more i'm not very familiar with sql-server coding conventions.
I will look it up on the internet.

the main issue is that I couldn't get the original trigger to work
because if my trigger returned more then one row i would get an error.
I've got an example in postgreSQL where the trigger works with the "for
each row function". but SQL-server 2000 doesn't support the "for each
row" statement!

But thank you for your advise, i will apply your advise the next time i
post an message!

--CELKO-- wrote:
Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, data types, etc. in
your schema are. Sample data is also a good idea, along with clear
specifications.

Your design sounds flawed. You have a customer_id which has a huge
size, and no way to validate it (check digit, anything??) Next, we
seldom use binary flags in SQL; instead we have a history with (start,
finish, status) triplets and/or an encodeing scheme for the status.

When I see a table named "CHECKED", I get scared. That is a status,
not an entity or relationship!! It means that you have split an
attribute out of an entity and made it into a separate table. If you
had a "MalePersonnel" and a "FemalePersonnel", you see the flaw of a
split on "sex" immediately.

Knowing that uppercase names are almost 10 times more often mis-read or
mis-typed, why did you use them? We had no choice in the days of
punchcards. In fact, you whoel design seems to be a punch card system
done in SQL.

You need to learn BASIC RDBMS, and how to use VIEWs.


Feb 21 '06 #4

P: n/a
SUKRU (as**********@hotmail.com) writes:
Thanks for the reply!
Your right I'm a beginner, but the example above is ficticious!
In fact there is no checked table! I made that up. I choose the checked
name just for practice sake. The original tables are in Dutch, i
wouldn't want to bother you with Dutch ;).


Heck why not? Most of Celko's posts are double-dutch anyway, so what's
the difference. :-)
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
Feb 21 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.