2009-10-21 11 views

Odpowiedz

4

OK, oto co się stało. Przed końcem SP istniała specjalna postać, więc w jakiś sposób była niekompletna, a mimo to nadal aktualna.

Więc mogłem zobaczyć SP i zobaczyć uprawnienia, ale nie mogłem go uruchomić. Aby rozwiązać ten problem, musiałem skopiować tekst z SQL Management Studio i wkleić go do Notatnika, następnie usunąć znak specjalny, a następnie skopiować i wkleić go z powrotem do SQL Management Studio i uruchomić skrypt zmiany.

Bardzo dziwne, jak ta postać się tam dostała!

1

Konto używane podczas wywoływania procedury składowanej nie może być tym samym kontem, którego używasz do sprawdzenia. Upewnij się, że konto używane do wykonania sproc ma dostęp do obiektu.

+0

Aplikacja internetowa podszywa się pod użytkownika domeny, który ma dostęp do przechowywanego procesu. Dotyczy to wszystkich pozostałych proc przechowywanych w systemie (w ponad 250 innych). I tylko ten problem daje. Próbowałem ponownie przypisać uprawnienia bez powodzenia. –

0

Zawsze używaj dbo. (lub inny schemat) przedrostek zarówno podczas tworzenia, jak i uzyskiwania dostępu do obiektów.

pisałem o tym samym temacie ostatnio:

http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/11/bad-habits-to-kick-avoiding-the-schema-prefix.aspx

+0

Przechowywany proces został utworzony z prefiksem schematu dbo i uzyskuję do niego dostęp za pośrednictwem bloku aplikacji Microsoft, czy to się liczy? –

+0

Niestety, nie wiem, co to jest "blok aplikacji Microsoft". Czy istnieje sposób, aby powiedzieć, aby zadzwonić "dbo.ProcedureName" zamiast tylko "ProcedureName"? –

0

jak również inne odpowiedzi dotyczące schematu/zabezpieczeń itp:

  • Masz ODMÓW na to gdzieś?
  • rozróżnianie wielkości liter w nazwach obiektów i używanie "niewłaściwej" nazwy?
  • zły kontekst bazy danych? np. OtherDB.dbo.Myproc
2

Podobny do zaznaczonej odpowiedzi: Ostatnim wierszem mojej procedury składowanej była linia, która udzieliła uprawnień do procedury składowanej, aby działała jako odpowiedni użytkownik - prawdopodobnie dodana tam, gdy wygenerowałem skrypt.

Usunięcie tego (lub prawdopodobnie ukrytego znaku) udało się naprawić.

"XXX" to nazwa procedury składowanej, którą zadzwoniłem, z powodzeniem (dokonała pożądanej zmiany), ale która dała mi ten błąd.

7

Odkryłem, że po "END" zostawiłem słowo "GO" w moim zapisanym proc. Zmiany w Proc i dodanie z powrotem GO rozwiązało ten problem dla mnie.

2

Spotykam się również z tym problemem. W moim przypadku udzieliłem zezwolenia na wykonanie zaraz po utworzeniu procedury przechowywanej. I nie ma "GO" między tymi dwoma stwierdzeniami. Dodałem GO i działa.

0

Użycie "GO" rozwiązało problem także dla mnie. To doprowadzało mnie do szaleństwa, po wielu kroplach i sprawdzaniu uprawnień dla użytkowników i schematów, to właśnie pomogło.

0

W serwerze Microsoft SQL zaznacz obiekt w eksploratorze obiektów, z którym chcesz pracować, klikając go prawym przyciskiem myszy, a następnie wykonaj polecenie "Script [object] as", aby uzyskać skrypt potrzebny do pomyślnego wykonania operacji bez uzyskanie tego błędu

-1

Jeśli upewniłeś się, że obiekt istnieje i nadal otrzymujesz błąd uprawnień, konieczne może być uruchomienie SQL Management Studio z uprawnieniami administratora. To powinno dać mu niezbędne uprawnienia do uzyskania dostępu do obiektu.

Powiązane problemy