September 11, 2007 at 2:45 pm
Hi,
I am trying to create a stored procedure to run through all the tables I have with triggers already enabled and disable them. I keep getting errors when trying to create the sp.
My code:
CREATE PROC sp_disableTriggers
AS
DECLARE
@temp_tablename VARCHAR(255)
, @temp_triggername VARCHAR(255)
, @statustype INT
DECLARE c_disableTrigger CURSOR
FOR
SELECT SubString(S2.Name,1,30) as [Table]
, SubString(S.Name, 1, 30) as [Trigger]
, CASE (SELECT -- Correlated subquery
OBJECTPROPERTY(OBJECT_ID(S.Name), 'ExecIsTriggerDisabled'))
WHEN 0 THEN 'Enabled'
WHEN 1 THEN 'Disabled'
END as Status
FROM Sysobjects S
JOIN Sysobjects S2 ON s.parent_obj = S2.ID
WHERE s.Type = 'TR'
OPEN c_disableTrigger
FETCH c_disableTrigger INTO @temp_tablename, @temp_triggername, @statustype
WHILE (@@fetch_status = 0)
IF @statustype = 0
BEGIN
ALTER TABLE @temp_tablename
DISABLE TRIGGER @temp_triggername
END
FETCH c_disableTrigger INTO @temp_tablename, @temp_triggername, @statustype
END
CLOSE c_disableTrigger
DEALLOCATE c_disableTrigger
********************
Error Message:
Msg 102, Level 15, State 1, Procedure sp_disableTriggers, Line 27
Incorrect syntax near '@temp_tablename'.
Msg 156, Level 15, State 1, Procedure sp_disableTriggers, Line 33
Incorrect syntax near the keyword 'CLOSE'.
I am guessing the CLOSE error is due to the error on temp_tablename.
Any comments are welcome.
Thanks,
______________________________
AJ Mendo | @SQLAJ
September 11, 2007 at 3:07 pm
You can't use a variable name to reference the tables/triggers. You'd have to parse it in using dynamic SQL.
My concern is, however, that usually having to disable triggers like this is a sign of either bad application design, bad database design, or both.
September 11, 2007 at 3:19 pm
Aaron,
Thanks for your comment about the tables/trigger names.
But I posted my code for assistance NOT negative comments.
You would be more helpful to leave them out.
______________________________
AJ Mendo | @SQLAJ
September 11, 2007 at 3:38 pm
I figured if I was in your shoes, I'd rather reconsider the potential ramifications of potentially (granted, I haven't seen your app or db) problematic design now rather than when it truly causes issues down the line. Take my experience as you will, however.
September 11, 2007 at 3:40 pm
Point taken.
Respectfully
______________________________
AJ Mendo | @SQLAJ
September 11, 2007 at 3:42 pm
I didn't think Aaron was being negative. It sounds like a perceptive observation to me. Look up EXEC in BOL. You need to build your ALTER TABLE statement into a variable and run it through EXEC or sp_executesql.
September 11, 2007 at 7:19 pm
It wasn't negative!!! It was friendly advise that you're probably commiting some form of SQL suicide by needing to do this!!!
There's only one reason to do such a thing and you didn't mention why you needed to do this. Instead of getting in a huff about negative comments, maybe you should evaluate what was said and ask a thoughtful "What do you mean"? Maybe even learn how to post a complete scenario
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy