W testtable
bazie danych utworzyłem tabelę testbase
o następującej strukturze:
product_no (int, not null)
product_name (varchar(30), not null)
price (money, null)
expire_date (date, null)
expire_time (time(7), null)
którego użyłem Microsoft SQL Server 2008 Management Studio.
Utworzyłem procedurę składowaną testtable_pricesmaller
w następujący sposób
use testbase
go
create procedure testtable_pricesmaller
@pricelimit money
as
select * from testtable where price = @pricelimit;
go
i mogą przeglądać Procedury przechowywane Object Explorer
w Microsoft SQL Server Management Studio. (Jest wymienione w poniższej strukturze drzewa Object Explorer
)
Databases
+ testbase
+ Tables
+ dbo.testtable
+ Programmability
+ Stored Procedures
+ dbo.testtable_pricesmaller
To bardzo dziwne, gdy pojawia się następujący błąd:
Could not find the stored procedure 'dbo.testtable_pricesmaller'.
kiedy wykonuję następującą instrukcję SQL:
execute dbo.testtable_pricesmaller 50
Czego mogło brakować?
USE
instrukcję, ale daje mi błąd.Odpowiedzi:
Lokalna pamięć podręczna IntelliSense Refresh powinna to naprawić
źródło
Nie trzeba ponownie uruchamiać bazy danych po dodaniu nowej procedury składowanej, chociaż konieczne będzie odświeżenie eksploratora obiektów, aby ją tam zobaczyć.
Następnym razem, gdy dodasz procedurę przechowywaną, spróbuj uruchomić opcję Eksploratora obiektów po kliknięciu prawym przyciskiem myszy, wprowadź parametry i sprawdź, czy się uruchomi. Jeśli nie działa, nie jestem pewien, na czym polega twój problem. Jeśli się uruchomi, może to być coś prostego, np. SQL próbuje wykonać zapytanie z niewłaściwej bazy danych.
źródło
W końcu wiem, dlaczego komunikat pojawia się w MS SQL Server Management Studio.
MS SQL Server Management Studio wymaga ponownego uruchomienia po utworzeniu w nim procedury składowanej.
Po ponownym uruchomieniu MS SQL Server Management Studio nie ma już takiego błędu.
(Dziwne, czy to oznacza, że za każdym razem, gdy tworzę procedurę składowaną, muszę ją ponownie uruchomić?)
źródło
Twoje polecenie tworzenia powinno być
brakuje
dbo.
przed nazwą procedury. Za każdym razem, gdy tworzysz procedurę, dobrą praktyką jest jawne zdefiniowanie użytkownika / schematu za pomocą nazwy procedury, tzn. Nazwa procedury powinna mieć w pełni kwalifikowane podpisy.Mam nadzieję, że to Ci pomoże.
źródło
W SQL Server 2008, jeśli zalogujesz się na koncie Windows, jeśli nie masz poziomu bezpieczeństwa SYSADMIN, kiedy utworzysz obiekt bez wyraźnego określenia schematu, może on / utworzy go pod nazwą [DOMENA \ nazwa użytkownika]. [NazwaObiektu ] zamiast [dbo]. [ObjectName] (myślę, że zostało to naprawione w SQL Server 2012).
Miałem ten problem, gdy obniżyłem poziom bezpieczeństwa użytkownika, a jedną z wykonywanych przez niego procedur było upuszczanie i odtwarzanie tabel bez schematu, więc reszta procedury ulegała awarii, ponieważ nie mogła ponownie uzyskać dostępu do obiektu . Okazuje się, że tabele zostały teraz utworzone pod jego nazwą użytkownika domeny.
Oto post Microsoft o tym zachowaniu:
https://docs.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-2017 (patrz sekcja „Schemat niejawny i tworzenie użytkownika”)
Tabela nie jest tworzona w schemacie dbo
SQL 2008 R2 tworzy użytkownika / schemat, gdy użytkownik systemu Windows tworzy tabele
Krótko mówiąc, prawdopodobnie masz problem z bazą danych (tworzysz tabelę w bazie danych, ale próbujesz uzyskać do niej dostęp z innej) lub masz problem taki, jak właśnie opisałem.
źródło
Wiem, że to jest stare; Natknąłem się na to pytanie, gdy szukałem rozwiązania tego samego problemu, i zamieszczam tę odpowiedź w nadziei, że pomoże to innym, którzy również znajdą to pytanie.
W moim przypadku otrzymałem komunikat o błędzie podczas uruchamiania raportu SSRS przy użyciu udostępnionego źródła danych. To współużytkowane źródło danych nie określiło domyślnej bazy danych (parametr Default Catalog =) i nie mogłem dodać jej do ciągu połączenia, ponieważ nie mam hasła (a kiedy zmieniasz coś w źródle danych SSRS, ma tendencję aby ponownie wprowadzić hasło).
Aby rozwiązać ten problem, zmieniłem domyślną bazę danych logowania w instancji SQL Server z głównej na bazę danych zawierającą procedurę przechowywaną, którą raport chciał wykonać.
Podczas uruchamiania rzeczy z SSMS pamiętaj, że okienko Eksploratora obiektów jest jednym połączeniem, podczas gdy dowolny edytor, który masz, jest zupełnie innym połączeniem. Więc możesz zobaczyć obiekty dla SQL01 w Object Explorerze, ale kod, który uruchamiasz w edytorze, będzie działał przeciwko SQL02 - Zetknąłem się z tym problemem kilka razy przez lata i po wielu przekleństwach i „Dlaczego nie działa?" zrozumiał mój błąd. W przypadku edytora spójrz w prawym dolnym rogu, aby zobaczyć, z którą instancją i bazą danych jesteś podłączony.
źródło
TL; DR: Być może masz procedurę składowaną, która wywołuje inną procedurę przechowywaną, która nie istnieje.
Miałem ten problem i znalazłem rozwiązanie. Oto co się stało. Utworzyłem jedną procedurę składowaną:
Następnie utworzyłem inną procedurę składowaną, która wykonała pierwszą
Jakiś czas później zmieniłem nazwę
dbo.MyProc
nadbo.MyProc2
. Po zmianie nazwy, gdy próbowałem zadzwonić, pojawiadbo.MyProcCaller
się następujący komunikat o błędzie:Moim rozwiązaniem było zmodyfikowanie mojej drugiej procedury składowanej, aby użyć nowej nazwy:
Oto prosty sposób sprawdzenia, czy masz ten problem. Kliknij, aby zmodyfikować tekst procedury składowanej, a następnie wykonaj ten tekst. Jeśli pojawi się takie ostrzeżenie, musisz zmienić nazwę procedury składowanej:
źródło
To pytanie ma kilka lat, ale chcę po prostu wprowadzić inną możliwość dla każdego takiego jak ja, który znalazł to później.
Uruchomiłem to polecenie: EXEC SP_CONFIGURE „Agent XPs”
I otrzymałem opisany błąd: Msg 2812, poziom 16, stan 62, wiersz 1 Nie można znaleźć procedury składowanej „SP_CONFIGURE”.
Ale potem przypomniałem sobie, że na tym serwerze jest rozróżniana wielkość liter. Więc to polecenie działało dobrze: EXEC sp_configure 'Agent XPs'
HTH
źródło