# "Could not find stored procedure' even though the stored procedure have been created in MS SQL Server Management Studio

I have created a table testtable inside the database testbase that 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 testtable_pricesmaller as follows

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 Explorer of the Microsoft SQL Server Management Studio. (It is listed in the following tree structure of the Object Explorer)

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. – Shawn Melton Sep 10 '12 at 5:24
• Yes, I did add the USE statement but it give me the error. – Jack Sep 10 '12 at 5:37
• I had to explicitly define the database name in my execute statement: EXEC [testbase].[dbo].[testtable_pricesmaller] 50 – Jroonk Oct 14 '15 at 19:42

IntelliSense Refresh local Cache should fix it

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.

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. – Shawn Melton Sep 10 '12 at 8:55
• @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? – Jack Sep 10 '12 at 9:15
• 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. – Thomas Stringer Sep 10 '12 at 16:03
• @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. – Jack Sep 11 '12 at 9:55
• For future reference: Ctrl-Shift-R will refresh the local cache, for intellisense. – Adam Scharp Jan 20 '16 at 21:20

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 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.

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.

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")

Table not getting created under dbo schema

SQL 2008 R2 creates user/schema when Windows user creates tables

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.

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.MyProc to dbo.MyProc2. After renaming it, when I tried to call dbo.MyProcCaller, I'd get this error message:

exec dbo.MyProcCaller


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'

HTH

## protected by Paul White♦Apr 22 '15 at 10:10

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).