web-dev-qa-db-fra.com

«Impossible de trouver la procédure stockée» même si la procédure stockée a été créée dans MS SQL Server Management Studio

J'ai créé une table testtable à l'intérieur de la base de données testbase qui a la structure suivante:

product_no (int, not null)
product_name (varchar(30), not null)
price (money, null)
expire_date (date, null)
expire_time (time(7), null)

que j'ai utilisé Microsoft SQL Server 2008 Management Studio.

J'ai créé une procédure stockée testtable_pricesmaller comme suit

use testbase
go
create procedure testtable_pricesmaller
    @pricelimit money
as
select * from testtable where price = @pricelimit;
go

et sont en mesure d'afficher les procédures stockées sur le Object Explorer de Microsoft SQL Server Management Studio. (Il est répertorié dans l'arborescence suivante du Object Explorer)

Databases
    + testbase
        + Tables
            + dbo.testtable
        + Programmability
            + Stored Procedures
                + dbo.testtable_pricesmaller

Je trouve cela très étrange lorsque je reçois l'erreur suivante:

Could not find the stored procedure 'dbo.testtable_pricesmaller'.

lorsque j'exécute l'instruction SQL suivante:

execute dbo.testtable_pricesmaller 50

Que pourrait-il manquer?

sql-server-2008stored-proceduresssms
21
Jack

Je sais enfin pourquoi le message apparaît dans MS SQL Server Management Studio.

MS SQL Server Management Studio en nécessite un pour le redémarrer après avoir créé une procédure stockée.

Après avoir redémarré MS SQL Server Management Studio, il n'y a plus une telle erreur.

(Étrange, cela signifie-t-il que chaque fois que je crée une procédure stockée, je dois la redémarrer?)

4
Jack

 IntelliSense Refresh local Cache devrait le réparer

19
user63684

Vous ne devriez pas avoir à redémarrer la base de données après avoir ajouté une nouvelle procédure stockée, bien que vous deviez actualiser votre explorateur d'objets pour le voir là-bas.

La prochaine fois que vous ajouterez une procédure stockée, essayez d'exécuter l'option de clic droit à partir de l'explorateur d'objets et entrez vos paramètres et voyez si elle s'exécute. Si cela ne fonctionne pas, je ne sais pas quel est votre problème. S'il s'exécute, cela pourrait être quelque chose de simple comme SQL essaie d'interroger à partir de la mauvaise base de données.

7
Zane

Votre commande create doit être

create procedure dbo.testtable_pricesmaller
    @pricelimit money

tu es absent dbo. avant le nom de la procédure. Chaque fois que vous créez une procédure, il est recommandé de définir explicitement l'utilisateur/schéma avec le nom d'une procédure, c'est-à-dire que le nom de la procédure doit avoir des signatures complètes.

J'espère que cela t'aidera.

3
Saim Saboor

Dans SQL Server 2008, lorsque vous êtes connecté sous un compte Windows, si vous n'avez pas le niveau de sécurité SYSADMIN, lorsque vous créez un objet sans spécifier explicitement le schéma, il peut/va le créer sous le [DOMAINE\nom d'utilisateur]. [ObjectName ] au lieu de [dbo]. [ObjectName] (il a été corrigé dans SQL Server 2012 je pense).

J'ai eu ce problème quand j'ai réduit le niveau de sécurité d'un utilisateur, et l'une des procédures qu'il exécutait était de supprimer et de recréer des tables sans schéma, donc le reste de la procédure se bloquait car il ne pouvait plus accéder à l'objet . Il s'avère que les tables ont maintenant été créées sous son nom d'utilisateur de domaine.

Voici le message de Microsoft sur ce comportement:

https://docs.Microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-2017 (recherchez la section " Schéma implicite et création d'utilisateurs ")

La table n'est pas créée sous le schéma dbo

SQL 2008 R2 crée un utilisateur/schéma lorsque l'utilisateur Windows crée des tables

Donc, en bref, vous avez probablement soit un problème de base de données (vous créez votre table dans une base de données mais essayez d'y accéder à partir d'une autre) ou vous avez le problème comme je viens de le décrire.

3
Philippe

Je sais que c'est vieux; Je suis tombé sur cette question alors que je cherchais une solution à ce même problème, et je poste cette réponse dans l'espoir que cela aide les autres qui trouvent également cette question.

Dans mon cas, j'ai reçu le message d'erreur lors de l'exécution d'un rapport SSRS à l'aide d'une source de données partagée. Cette source de données partagée n'a pas spécifié de base de données par défaut (paramètre Default Catalog =), et je n'ai pas pu l'ajouter à la chaîne de connexion car je n'ai pas le mot de passe (et lorsque vous modifiez quelque chose dans une source de données SSRS, il a tendance à pour que vous ressaisissiez le mot de passe).

Pour résoudre ce problème, j'ai changé la base de données par défaut pour la connexion dans l'instance SQL Server de maître à la base de données contenant la procédure stockée que le rapport voulait exécuter.

Lorsque vous exécutez des choses à partir de SSMS, gardez à l'esprit que le volet Explorateur d'objets est une connexion alors que l'éditeur que vous avez est une connexion entièrement différente. Ainsi, vous pouvez voir les objets pour SQL01 dans l'Explorateur d'objets, mais le code que vous exécutez dans un éditeur s'exécutera contre SQL02 - J'ai rencontré ce problème plusieurs fois au fil des ans et après de nombreuses discussions et "Pourquoi ne pas ça marche?" réalisé mon erreur. Pour l'éditeur, regardez dans le coin inférieur droit pour voir à quelle instance et base de données vous êtes connecté.

2
S M

TL; DR: Vous pouvez avoir une procédure stockée qui appelle une autre procédure stockée qui n'existe pas.

J'ai eu ce problème et j'ai trouvé un correctif. Voici ce qui s'est passé. J'ai créé une procédure stockée:

create procedure dbo.MyProc
    ...

J'ai ensuite créé une autre procédure stockée qui a exécuté la première

create procedure dbo.MyProcCaller
    ...
    exec dbo.MyProc
    ...

Quelque temps plus tard, j'ai renommé dbo.MyProc à dbo.MyProc2. Après l'avoir renommé, lorsque j'ai essayé d'appeler dbo.MyProcCaller, J'obtiendrais ce message d'erreur:

exec dbo.MyProcCaller

Impossible de trouver la procédure stockée 'RLM.usp_getSecondaryRestrictedLists_Old'.

Ma solution a été de modifier ma deuxième procédure stockée pour utiliser le nouveau nom:

create procedure dbo.MyProcCaller
    ...
    exec dbo.MyProc2
    ...

Voici un moyen simple de vérifier si vous rencontrez ce problème. Cliquez pour modifier le texte de la procédure stockée, puis exécutez ce texte. Si vous recevez un avertissement comme celui-ci, vous devez renommer votre procédure stockée:

Le module 'dbo.MyProcCaller' dépend de l'objet manquant 'dbo.MyProc'. Le module sera toujours créé; cependant, il ne peut pas s'exécuter correctement tant que l'objet n'existe pas.

(1 ligne (s) affectée (s))

1
user2023861

Cette question remonte à quelques années, mais je veux simplement proposer une autre possibilité à toute personne comme moi qui l'a trouvée plus tard.

J'ai exécuté cette commande: EXEC SP_CONFIGURE 'Agent XPs'

Et obtenu l'erreur décrite: Msg 2812, niveau 16, état 62, ligne 1 Impossible de trouver la procédure stockée 'SP_CONFIGURE'.

Mais je me suis alors souvenu que ce serveur était configuré pour être sensible à la casse. Cette commande a donc très bien fonctionné: EXEC sp_configure 'Agent XPs'

HTH

0
jrdevdba