Determine what procedure/function called a stored procedure

Is there a way within a proc to determine what object called it?
ex:
DB1.dbo.ProcA calls DB2.dbo.ProcB. From within ProcB, is there any means to
get the context (name or id) of the procedure or function that called it?
Thanks!I don't think so. I think all you get is @.@.NESTLEVEL
However you can set sysprocesses.CONTEXT_INFO
I've used it to bypass triggers before.
http://www.sqlservercentral.com/col...ingtriggers.asp
In this case it's much the same as updating an @.@.spid based table.
Paul
"Travis" <Travis@.discussions.microsoft.com> wrote in message
news:047E3AF3-D480-4246-899B-A0616B51F179@.microsoft.com...
> Is there a way within a proc to determine what object called it?
> ex:
> DB1.dbo.ProcA calls DB2.dbo.ProcB. From within ProcB, is there any means
> to
> get the context (name or id) of the procedure or function that called it?
> Thanks!|||nrgh...that is what I was afraid of. :)
I have to modify some existing procedures and the original implementation
has led to some issues in logging information. I was hoping to avoid
changing about 1000 procs to pass in the DBID that it was executed on. *sig
h*
Thanks for the confirmation.
"Paul Cahill" wrote:

> I don't think so. I think all you get is @.@.NESTLEVEL
> However you can set sysprocesses.CONTEXT_INFO
> I've used it to bypass triggers before.
> http://www.sqlservercentral.com/col...ingtriggers.asp
> In this case it's much the same as updating an @.@.spid based table.
> Paul
>
>
> "Travis" <Travis@.discussions.microsoft.com> wrote in message
> news:047E3AF3-D480-4246-899B-A0616B51F179@.microsoft.com...
>
>|||The @.@.procid variable returns the procedure identifier of the current
procedure. Perhaps you can add a parameter to each SP @.called_by and call
procedures like so:
exec @.proc2 @.called_by = @.@.procid
"Travis" <Travis@.discussions.microsoft.com> wrote in message
news:047E3AF3-D480-4246-899B-A0616B51F179@.microsoft.com...
> Is there a way within a proc to determine what object called it?
> ex:
> DB1.dbo.ProcA calls DB2.dbo.ProcB. From within ProcB, is there any means
> to
> get the context (name or id) of the procedure or function that called it?
> Thanks!|||There's been a few times I'd like to be able to get at the stack too.
Anyone out there know a trick?
If these were remote calls I think it could be done by setting up the linked
servers such that rpc's always connect as a particular user.
If each link is given a different username can you then tell which server
remotely called the proc.
But you are executing all on the same machine just from different databases.
"Travis" <Travis@.discussions.microsoft.com> wrote in message
news:DA1631A4-10C6-4037-97F1-C5D58327B16A@.microsoft.com...
> nrgh...that is what I was afraid of. :)
> I have to modify some existing procedures and the original implementation
> has led to some issues in logging information. I was hoping to avoid
> changing about 1000 procs to pass in the DBID that it was executed on.
> *sigh*
> Thanks for the confirmation.
> "Paul Cahill" wrote:
>|||The procID is being passed into the procedure, but it will need to pass in
the DBID as well. There are multiple DBs on the server and it recently came
to light that the logic in the proc to determine which DB the proc was
executed on is incorrect (as the procIds can be the same in multiple dbs).
: )
Thx
"JT" wrote:

> The @.@.procid variable returns the procedure identifier of the current
> procedure. Perhaps you can add a parameter to each SP @.called_by and call
> procedures like so:
> exec @.proc2 @.called_by = @.@.procid
> "Travis" <Travis@.discussions.microsoft.com> wrote in message
> news:047E3AF3-D480-4246-899B-A0616B51F179@.microsoft.com...
>
>|||If you are wanting to peform procedure call stack tracing for debugging
purposes, then look into using SQL Profiler for this. It would require no
programming changes.
http://msdn.microsoft.com/library/d...nEventClues.asp
"Travis" <Travis@.discussions.microsoft.com> wrote in message
news:4C79AB11-F7D1-40DD-BB52-0063E138D8C4@.microsoft.com...
> The procID is being passed into the procedure, but it will need to pass in
> the DBID as well. There are multiple DBs on the server and it recently
> came
> to light that the logic in the proc to determine which DB the proc was
> executed on is incorrect (as the procIds can be the same in multiple dbs).
> : )
> Thx
> "JT" wrote:
>