November 18, 2004 at 4:49 am
I have a couple of triggers on a table - one an insert and the other an update. It works fine, but I need to drop it and I cant. If I try to edit it, the whole database becomes unusable - hence my attempts to drop it. I tried dropping it using OSQL overnight, but still the same problem.
I've trawled the Internet for similar problems, but to no avail.
Any help/Comment appreciated. I can post the SQL if needed.
BillC
November 18, 2004 at 5:25 am
Are you trying to drop it via DROP TRIGGER? Maybe you should post your statement.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
November 18, 2004 at 5:28 am
Frank
this is the script that I was trying to run last night:
use MaintSQL
go
drop Trigger dbo.NewTblProperty_TriggerUpdateSurveyor
go
drop Trigger dbo.NewTblProperty_UpdateSurveyor
go
November 18, 2004 at 5:39 am
And what was the error message?
How did you try to run this?
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
November 18, 2004 at 5:43 am
I ran it from a batchfile I keep for these purposes. It runs nightly. The command line I used was:
osql -E -S Orinoco -i DropTriggersOnNewTblProperty.sql > 17112004_2.txt
there was no error message, just the DOS window had not closed signifying that the process had either hung or not terminated.
I did try to run the SQL in Analyser, but it just takes for ever and stops users from working.
Bill
November 18, 2004 at 5:51 am
So, as this sounds strange and as a kind of last resort, did you also try this from within Enterprise Manager? "Usually" this operations should only be a matter of moments.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
November 18, 2004 at 5:54 am
I usually do this in an ADP Access database, but yes, when that failed I tried it in Enterprise manager - hence the saga of trying to drop it via SQL
Bill
November 18, 2004 at 5:54 am
...but you are logged in with appropriate privileges, right?
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
November 18, 2004 at 6:54 am
This is probably not more than guessing, so bear with me
- you are in the right db?
- the triggers exists?
- they are not recreated by any other operation?
Hey, I'm running out of ideas.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
November 18, 2004 at 7:11 am
The triggers are :
NewTblProperty_TriggerUpdateSurveyor
and
dbo
.NewTblProperty_UpdateSurveyor
If I try to drop triggers that do not exist I get this:
Server: Msg 3701, Level 11, State 5, Line 1
Cannot drop the trigger 'dbo.xNewTblProperty_TriggerUpdateSurveyor', because it does not exist in the system catalog.
Server: Msg 3701, Level 11, State 5, Line 2
Cannot drop the trigger 'dbo.xNewTblProperty_UpdateSurveyor', because it does not exist in the system catalog.
I've just noticed that the first trigger does not have dbo as the prefix Would that make a difference?
Thanks for your efforts by the way.
Bill
November 19, 2004 at 7:56 am
I've already experienced something like this. What "made it work" was that I restarted EM and the offending objects were gone. For some reason the refresh methods didn't work in this context.
November 19, 2004 at 8:01 am
This won't work here, I've been trying to do this for weeks. EM has been restarted numerous times and the server re-booted.
November 19, 2004 at 8:33 am
Ok, the only other thing I can think of is trying to drop the table and recreate it (almost like EM does when you save the changes made to a table).
Maybe you can script the table with the indexes, foreign keys and constraints including the new triggers. Then create the table under MyTableName_2. Ship the data from the old table, drop the old table and then rename the new table to the correct name.
Other than that I have no idea how to help you.
Good luck.
November 19, 2004 at 8:38 am
Hmm, I was saving that as a last resort in case someone could come up with and explanation and/or solution. Its looking increasingly likely that the table will have to go. still, thanks anyway.
November 19, 2004 at 8:48 am
Looks to me like you have the situation under controle... Just make sure you have a full backup of the database before reloading the table... in case another bug screws the server and you have to reinstall. It shouldn't be a problem... but then again you shouldn't have this problem in the first place, so better safe than sorry.
Let us know how this goes.
Viewing 15 posts - 1 through 15 (of 15 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