views:

162

answers:

5

If Proc A executes Proc B, is there a way for Proc B to look-up that it was called by A instead of having a parameter where A passes B its ID?

Per request: The reason I'm interested in this is multi-fold 1) General knowledge, I'm sure if it can be done it would involve clever use of some system tables/variables that may help me do other things down the road.

2) As others have mentioned, logging/auditing. I'd like to make a procedure that logs a begin, end and message entry that requires no parameters, and accepts one optional parameter of a user specified message. This would allow one to simply drop an exec in the top and bottom of a proc to make it work and the audit procedure would figure out the rest on its own.

I know this info is available in the log files, but parsing those and giving them to users is not all that straight forward, whereas, this would give easy access to that basic info.

3) Used in conjunction with a semaphore such a generalized procedure could ensure that related processes are not executed simultaneously regardless of sessions/transactions etc.

A: 

Why would you want to do that?
AFAIK, there is no way for proc B to know who called it.

EDIT: As KM shows that it is possible (as per the code), I am interested in understanding the reason behind doing this. Can you post that as well, by adding it to your question?

shahkalpesh
I've done this before to help log events. In important/problematic procedures, I keep appending a usefull info onto a varchar(8000) varibale as the procedure does various things. When there is an error, I rollback and insert this string into a log table, which has much usefull info in it. Sometimes knowing who called the procedure helps and can be recorded with the other info...
KM
I thought so. Same as StackTrace for stored procedure. Thanks KM.
shahkalpesh
I don't nest procedure calls all that deep. I've used this technique to track a procedure that was called from numerous locations. It is one thing to know you have bad parameters, and another to know where they are coming from
KM
Is there someway in SQL to get the list of statements being executed (the way profiler sees it)?
shahkalpesh
I don't know, but it is possible to debug into a stored procedure.
John Saunders
A: 

If a stored procedure needs to behave differently based on who calls it, then it needs to add a parameter. That way, if you add stored procedure "Z", the code will still work - "Z" can pass the parameter the way that "C" passed it, or the way "D" passed it. If that's not good enough, then new logic needs to be added in "B".

John Saunders
+1  A: 

no, it cant tell what sproc called it. You'd need to add an extra parameter in to tell it who the caller is

AdaTheDev
There might be some extremely convoluted code you could write that hits the system views, tracking and parsing through call stacks... but I don't know that the information is there, or if it'd be worth the effort.
Philip Kelley
+3  A: 

use a prarameter like this:

CREATE PROCEDURE ParentProcedure

AS

DECLARE @ProcID             int

SET @ProcID=@@PROCID

EXEC ChildProcedure @ProcID

RETURN 0
go

and this...

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

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

RETURN 0
go
KM
A: 

In MSSQL Server 2008 you can use sys.dm_exec_procedures_stats, this dynamic management view can show you when stored procedure (see also sys.procedures to obtain name of the procedure) was executed and so on.

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;

Parent-procedure will be shown in this result set very close, because this procedure will be executed earlier. Of course, this is not complete solution of your problem, but you may obtain some info.

and yes, if there is concurrency, this solution doesn't works. It can help in development or debug only.

Alex_L