[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 237
  • Last Modified:

Can't Drop Stored Procedure

Hello Experts - I'm experiencing some strange behavior - for some reason I can't update a stored proc in SQL Server 2008 R2 Express. WHen I run an ALTER command, it runs fine, but if I execute the query, it keeps giving me the old version. When I try to drop the procedure, it tells me it doesn't exist. Then if I run it again, it runs fine, and with the old version. Can't update it, can't drop it - HUH??

Any ideas?

1 Solution
Kevin CrossChief Technology OfficerCommented:
Is it possible, it is in another database? i.e., did you accidentally create the procedure under master? What does the ALTER statement look like, how are you calling it when it works -- just really need the name part, i.e., schema.procname or db.schema.procname depending on how you are calling it...maybe something is in that to give us a clue.
mwvisa1 brings up a good point that i run into frequently.

Also, can you update anything else in the database? Is it possible that the procedure is in a different namespace? e.g. myname.spMyProcedure instead of dbo.spMyProcedure
Probably you run it in the wrong DB. Try to use :

USE [YourDBName]

Open in new window

when ALTER or RUN your SP.

Hopei it helps...
Free Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

Brian ChanDBACommented:
Just a quick thought, did you check which schema did you set to default for? This happened to one of my developers who came yelling at me one day about why his dropped SP still alive. And what I found is that he was set to default schema as some temp schema instead of dbo. So when he creates or drops objects, SQL Server will look at his default schema in the first place. In no offense, I wish you are not in the same position.
I am giving you some queries which will help you
in which database your required (Corrected Useful ) Stored Procedure residing then
then you can recognize them then either you want to EDIT or DROP them

SELECT name, create_date, modify_date
FROM sys.objects
WHERE type = 'P'
AND name = 'your Stored Procedure name'

Let's say you are searching for 'foobar' in all your stored procedures. You can do this using the INFORMATION_SCHEMA.ROUTINES view, or syscomments:

tablaFreakAuthor Commented:
Thanks for your suggestions, and yes, I've fallen prey to not running queries on the right db before, but that wasn't the case this time - when I ran that query you sent, AlokJain0412, two SPs came up with the same name. I had to run the Drop Procedure... query twice, then recreate it for the old version to actually be updated. Must have just been cached somewhere - it's working now, thanks, but I'm still baffled why simply running the 'Alter procecure' statement didn't update it. Mysteries...

tablaFreakAuthor Commented:
fixed the problem, but the underlying reason remains a mystery.
Kevin CrossChief Technology OfficerCommented:
The query supplied included neither the CATALOG nor the SCHEMA, so mystery would have been removed by seeing where they lived. Anyway, glad you are fixed now. :)
tablaFreakAuthor Commented:
Gotchya - thanks, if it happens again I'll know what to do. Cheers.

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now