"Could not find stored procedure' even though the stored procedure have been created in MS SQL Server Management Studio
I have created a table
testtableinside the database
testbasethat have the following structure:
product_no (int, not null) product_name (varchar(30), not null) price (money, null) expire_date (date, null) expire_time (time(7), null)
which I used the Microsoft SQL Server 2008 Management Studio.
I created a stored procedure
use testbase go create procedure testtable_pricesmaller @pricelimit money as select * from testtable where price = @pricelimit; go
and are able to view the Stored Procedures on the
Object Explorerof the Microsoft SQL Server Management Studio. (It is listed in the following tree structure of the
Databases + testbase + Tables + dbo.testtable + Programmability + Stored Procedures + dbo.testtable_pricesmaller
I find it very strange when I receive the following error:
Could not find the stored procedure 'dbo.testtable_pricesmaller'.
when I execute the following SQL statement:
execute dbo.testtable_pricesmaller 50
What could it be missing?
Did you make sure your execute statement is running under the context of "testbase" database? You might try adding a USE statement or fully qualifying the object name.
At last I know why the message appear in the MS SQL Server Management Studio.
The MS SQL Server Management Studio require one to restart it after creating a stored procedure in it.
After restarting the MS SQL Server Management Studio, there is no such error anymore.
(Strange, does that mean that every time I create a stored procedure, I have to restart it?)
You should not have to restart it.
@ShawnMelton I mean that I close the MS SQL Server Management Studio and re-open the MS SQL Server Management Studio. I just find it quite strange that I have to close and then re-open it. Is there any configuration of the MS SQL Server Management Studio (SSMS) that I might be missing, resulting the SSMS unable to reflect that the Stored Procedure is already created?
IntelliSense is the only lagging portion of what you did. Executing the exec statement should have worked without restarting SSMS. There is something else that contributed to it not working. I agree with @ShawnMelton.
@Shark, Interesting! I would appreciate if anyone can explain to me that why my SSMS behave in such way that I find it quite strange.
You should not have to restart the database after adding a new stored procedure, although you will need to refresh your object explorer to see it there.
The next time you add a stored procedure try running the right click execute option from the object explorer and enter your parameters and see if it runs. If it does not run then I'm not sure what your problem is. If it does run then it could be something simple like SQL is trying to query from the wrong database.
In SQL Server 2008, when logged in under a Windows account, if you don't have SYSADMIN security level, when you create an object without explicitly specifying the schema, it may/will create it under the [DOMAIN\username].[ObjectName] instead of [dbo].[ObjectName] (it was fixed in SQL Server 2012 I think).
I had this problem happen to me when I reduced a user' security level, and one of the procedure he was executing was dropping and recreating tables without a schema, so the rest of the procedure was crashing because it couldn't access the object again. Turns out the tables were now created under his domain username.
Here is the Microsoft post about this behavior:
https://docs.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-2017 (look for the section "Implicit Schema and User Creation")
So, in short, you probably either have a database problem (you create your table in a database but try to access it from another one) or you have the problem like I just described.
Your create command should be
create procedure dbo.testtable_pricesmaller @pricelimit money
you are missing
dbo.before procedure name. Whenever you create a procedure, it is good practice to explicitly define the user/schema with the name of a procedure i.e. procedure name should have fully qualified signatures.
I hope this will help you.
I know this is old; I came across this question while I was searching for a solution to this very same problem, and I'm posting this answer in the hope that it helps others who also find this question.
In my case, I got the error message while running an SSRS report using a shared data source. This shared data source did not specify a default database (the Default Catalog= parameter), and I couldn't add it to the connection string because I don't have the password (and when you change something in an SSRS data source it tends to want you to re-enter the password).
To solve this, I changed the default database for the login in the SQL Server instance from master to the database containing the stored procedure the report wanted to execute.
When running things from SSMS, keep in mind the Object Explorer pane is one connection while whatever editor you have is an entirely different connection. So you may see the objects for SQL01 in Object Explorer, but the code you're running in an editor will run against SQL02 - I've run into this problem a few times over the years and after much cussing and "Why won't it work?" realized my mistake. For the editor, look in the lower right corner to see which instance and database you're connected to.
TL;DR: You may have a stored procedure that's calling another stored procedure that doesn't exist.
I had this problem and found a fix. Here's what happened. I created one stored procedure:
create procedure dbo.MyProc ...
I then created another stored procedure that executed the first one
create procedure dbo.MyProcCaller ... exec dbo.MyProc ...
Some time later, I renamed
dbo.MyProc2. After renaming it, when I tried to call
dbo.MyProcCaller, I'd get this error message:
Could not find stored procedure 'RLM.usp_getSecondaryRestrictedLists_Old'.
My solution was to alter my second stored procedure to use the new name:
create procedure dbo.MyProcCaller ... exec dbo.MyProc2 ...
Here's a simple way to check if you have this problem. Click to modify the text of the stored procedure and then execute that text. If you get a warning like this, you need to rename your stored procedure:
The module 'dbo.MyProcCaller' depends on the missing object 'dbo.MyProc'. The module will still be created; however, it cannot run successfully until the object exists.
(1 row(s) affected)
This question is a few years old, but I just want to throw in another possibility for anyone like me who found it later.
I ran this command: EXEC SP_CONFIGURE 'Agent XPs'
And got the error described: Msg 2812, Level 16, State 62, Line 1 Could not find stored procedure 'SP_CONFIGURE'.
But then I remembered that this server is set up to be case-sensitive. So this command worked just fine: EXEC sp_configure 'Agent XPs'