2009-07-17 13 views
6

Jeśli Proc A wykonuje Proc B, czy istnieje sposób dla Proc B do sprawdzenia, czy został wywołany przez A zamiast mieć parametr, w którym A przekazuje B swój identyfikator?Czy procedura składowana SQL Server może określić nazwę jej macierzystego procesu?

Na życzenie: powodem, dla którego jestem zainteresowany tym tematem, jest wielorakie 1) Ogólna wiedza, jestem pewien, że jeśli można to zrobić, wymagałoby to sprytnego użycia niektórych tabel/zmiennych systemowych, które mogą mi pomóc inne rzeczy na drodze.

2) Jak wspomnieli inni, rejestracja/audyt. Chciałbym wykonać procedurę, która loguje wpis początku, końca i komunikatu, który nie wymaga parametrów i akceptuje jeden opcjonalny parametr komunikatu określonego przez użytkownika. Pozwoliłoby to po prostu upuścić exec w górnej i dolnej części procesu, aby działało, a procedura audytowa sama zajmie się resztą.

Wiem, że te informacje są dostępne w plikach dziennika, ale ich analiza i przekazanie użytkownikom nie jest proste, a to dałoby łatwy dostęp do tych podstawowych informacji.

3) Używany w połączeniu z takiej procedury semafora uogólnionego mogłaby zapewnić, że związane z nimi procesy nie są wykonywane równocześnie, niezależnie od sesji/transakcji itp

Odpowiedz

0

Dlaczego chcesz to zrobić?
AFAIK, nie ma sposobu, aby proc B wiedział, kto to nazwał.

EDYCJA: Jak KM pokazuje, że jest to możliwe (zgodnie z kodem), jestem zainteresowany zrozumieniem przyczyny takiego postępowania. Czy możesz to również opublikować, dodając go do swojego pytania?

+0

Zrobiłem to wcześniej, aby pomóc w rejestrowaniu zdarzeń. W ważnych/problematycznych procedurach ciągle dołączam użyteczne informacje do varibale varchar (8000), ponieważ procedura wykonuje różne czynności. Gdy wystąpi błąd, wycofuję i wstawiam ten ciąg do tabeli dziennika, która zawiera wiele użytecznych informacji. Czasami wiedza, kto wezwał procedurę, pomaga i może być zapisana z innymi informacjami ... –

+0

Tak myślałem.Taki sam jak StackTrace dla procedury składowanej. Dzięki KM. – shahkalpesh

+0

Nie zagnieżdżam wywołań procedur tak głęboko. Użyłem tej techniki do śledzenia procedury, która została wywołana z wielu lokalizacji. Jedną rzeczą jest wiedzieć, że masz złe parametry, a inne wiedzieć, skąd pochodzą –

0

Jeśli procedura składowana musi zachowywać się inaczej w zależności od tego, kto ją wywołuje, wówczas musi dodać parametr. W ten sposób, jeśli dodasz procedurę składowaną "Z", kod nadal będzie działał - "Z" może przekazywać parametry w taki sposób, w jaki "C" je przekazał, lub sposób, w jaki "D" je przekazał. Jeśli to nie wystarczy, nowa logika musi zostać dodana w "B".

1

Nie, nie można powiedzieć, co sproc nazwał. trzeba by dodać dodatkowy parametr, by poinformować go, kim jest rozmówca jest

+2

Może istnieć jakiś niezwykle zawiły kod, który można napisać, który uderza w widoki systemu, śledząc i analizując stosy wywołań ... ale nie wiem, czy te informacje tam są, czy też warte wysiłku. –

4

Użyj prarameter tak:

CREATE PROCEDURE ParentProcedure 

AS 

DECLARE @ProcID    int 

SET @[email protected]@PROCID 

EXEC ChildProcedure @ProcID 

RETURN 0 
go 

i to ...

CREATE PROCEDURE ChildProcedure 
(
@ProcID int=null --optional 
) 
AS 

if @ProcID IS NOT NULL 
BEGIN 
    PRINT 'called by '+OBJECT_NAME(@ProcID) 
END 

RETURN 0 
go 
0

w MSSQL Server 2008 można użyć sys.dm_exec_procedures_stats, ten dynamiczny widok zarządzania może wyświetlić, gdy procedura składowana (patrz także sys.procedures, aby uzyskać nazwę procedury) została wykonana i tak dalej.

SELECT s.*, d.* 
FROM sys.procedures s 
INNER JOIN sys.dm_exec_procedure_stats d 
ON s.object_id = d.object_id 
ORDER BY [d.last_execution_time] DESC; 

Procedura dla rodziców będzie wyświetlana w tym zestawie wyników bardzo blisko, ponieważ ta procedura zostanie wykonana wcześniej. Oczywiście nie jest to kompletne rozwiązanie Twojego problemu, ale możesz uzyskać pewne informacje.

i tak, jeśli istnieje współbieżność, to rozwiązanie nie działa. Może pomóc w rozwoju lub debugowaniu tylko.

Powiązane problemy