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

Question

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?

Answer 1

IntelliSense Refresh local Cache should fix it

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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)

Answer 8

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

Answer 9

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

Answer 10

@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