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
create procedure testtable_pricesmaller
    @pricelimit money
select * from testtable where price = @pricelimit;

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)

    + 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?

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

10 Answers 10


IntelliSense Refresh local Cache should fix it

  • you helped, thumbup. Commented Dec 24, 2019 at 8:33
  • This worked. Using SSMS 18.
    – k_rollo
    Commented Sep 13, 2020 at 12:35
  • Thanks, this worked for me. It should be marked as the answer.
    – naseefo
    Commented Dec 14, 2021 at 18:55
  • 1
    @naseefo I don't think this is the answer at all. This just refreshes intellisense. It won't make any difference to execution. Commented Aug 2, 2022 at 15:01

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

  • 15
    You should not have to restart it.
    – user507
    Commented Sep 10, 2012 at 8:55
  • 2
    @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
    Commented Sep 10, 2012 at 9:15
  • 6
    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. Commented Sep 10, 2012 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
    Commented Sep 11, 2012 at 9:55
  • 7
    For future reference: Ctrl-Shift-R will refresh the local cache, for intellisense. Commented Jan 20, 2016 at 21:20

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://learn.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.


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.

  • It's good practice, but unnecessary. The user account responsible can specify a default schema that will be used when creating new objects.
    – Suncat2000
    Commented Jun 16, 2023 at 23:22

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.

  • First, this is not an old question. The problem occurs in the latest SSMS and occurs regardless of what instances you're running under and default database selected. This bug has existed now since 2012, it's now 2022 In 10 years, Microsoft hasn't fixed this problem.
    – ATL_DEV
    Commented Jan 1, 2022 at 18:58
  • 5 years in the programming industry is old. :-( SSMS allows you to have multiple connections open. It's not a bug. The problem is making sure you have selected the correct settings or connection prior to executing a query. That's as old as technology.
    – Suncat2000
    Commented Jun 16, 2023 at 23:28

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'


  • All the databases I've worked with use a default case-insensitive collation. For those that don't, this is an excellent answer.
    – Suncat2000
    Commented Jun 16, 2023 at 23:31

In a similar vain, I got this error calling from ASP.NET VB code behind and it was due to an extra space character in front of the stored procedure name e.g. " dbo.mysproc" instead of "dbo.mysproc".


@Zane's answer is the best answer. I will also add ... For those who are in Azure Data Studio, you can clear the cache by CTRL<CMD>-SHIFT-P and typing intellisense in the command palate. You will see an option to refresh the cache there. source

Not the answer you're looking for? Browse other questions tagged or ask your own question.