Profile Trace: how to tell which database when filtering on user

Let's say there are two databases, DB#1 and DB#2, and a user JOE. DB#1 and
DB#2 have stored procedures identically named (.e.g. "uspGetOrders") with
the same signature. Is it possible when running a trace that filters on
user like JOE, to determine which database the procedure belongs to which
JOE happens to be executing? How can I tell which it is? When I double
click on the trace line to view the details, the sp name is displayed
without a db or owner prefix. And if I filter on database name, I see this:
exec uspGetOrders @.p1 no matter which database I happen to choose. The
trace doesn't seem to tell me where the procedure "originates" so to speak.
I'm trying to figure out why the procedure is returning no data when it is
moved to DB#2 and points back to tables in DB1. The procedure worked fine
when it was in DB#1. The stored procedure refers to the table as
DB1.dbo.Orders and JOE has been granted execute privileges (via a role) on
DB2.dbo.uspGetOrders. JOE had no problem working with the procedure when
it was in the same database as the table. JOE belongs to a role that has
select privileges on Orders.
The only other thing that has changed is the Initial Catalog when JOE
connects. Now it is DB2.
Thanks!
TimoIf a user is in DB#1 and what you see executed is
uspGetOrders, it's executing the stored procedure in DB#1.
It would have to be qualified by the database name to
execute the stored procedure in DB#2.
If you are on SQL Server 2000 and if you are on SP3, then
the issue with the stored procedure could be due to not
having cross database ownership chaining enabled. If you are
running under this configuration and have updated your books
online, you can find more information in books online under
the topic:
Cross DB Ownership Chaining
-Sue
On Mon, 12 Apr 2004 12:25:28 -0400, "Timo"
<timo@.anonymous.com> wrote:

>Let's say there are two databases, DB#1 and DB#2, and a user JOE. DB#1 and
>DB#2 have stored procedures identically named (.e.g. "uspGetOrders") with
>the same signature. Is it possible when running a trace that filters on
>user like JOE, to determine which database the procedure belongs to which
>JOE happens to be executing? How can I tell which it is? When I double
>click on the trace line to view the details, the sp name is displayed
>without a db or owner prefix. And if I filter on database name, I see this
:
>exec uspGetOrders @.p1 no matter which database I happen to choose. The
>trace doesn't seem to tell me where the procedure "originates" so to speak.
>I'm trying to figure out why the procedure is returning no data when it is
>moved to DB#2 and points back to tables in DB1. The procedure worked fine
>when it was in DB#1. The stored procedure refers to the table as
>DB1.dbo.Orders and JOE has been granted execute privileges (via a role) on
>DB2.dbo.uspGetOrders. JOE had no problem working with the procedure when
>it was in the same database as the table. JOE belongs to a role that has
>select privileges on Orders.
>The only other thing that has changed is the Initial Catalog when JOE
>connects. Now it is DB2.
>Thanks!
>Timo
>
>
>|||Sue,
Thanks for the reply. It doesn't appear to be Cross DB Ownership chaining;
same issue after this:
EXEC sp_configure 'Cross DB Ownership Chaining', '0'; RECONFIGURE
EXEC sp_dboption 'DB1', 'db chaining', 'ON'
EXEC sp_dboption 'DB2', 'db chaining', 'ON'
Trace shows the procedure being invoked; the IN parameter is there, but all
the OUT parameters are null. When I've encountered similar symptoms in Trace
before, it was because the user lacked execute privileges on the procedure.
But JOE has these privileges by virtue of membership in a db role.
Any other way to troubleshoot this scenario using Trace?
Thanks again.
Timo
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:vcil70hj0j37239l9ds5tevbtfotc6n506@.
4ax.com...
> If a user is in DB#1 and what you see executed is
> uspGetOrders, it's executing the stored procedure in DB#1.
> It would have to be qualified by the database name to
> execute the stored procedure in DB#2.
> If you are on SQL Server 2000 and if you are on SP3, then
> the issue with the stored procedure could be due to not
> having cross database ownership chaining enabled. If you are
> running under this configuration and have updated your books
> online, you can find more information in books online under
> the topic:
> Cross DB Ownership Chaining
> -Sue
> On Mon, 12 Apr 2004 12:25:28 -0400, "Timo"
> <timo@.anonymous.com> wrote:
>
and
which
this:
speak.
is
on
when
>|||In Profiler, you'd want to select exceptions from the Errors
and Warnings event class. That will give you any errors
being raised. You should also make sure you are capturing
the completion of the stored procedure, not just the
starting event.
Did you check the owners of the objects (the stored
procedure and the underlying tables) and databases involved?
The databases need to be owned by the same login. The
objects need to have the same object owner.
-Sue
On Mon, 12 Apr 2004 13:40:39 -0400, "Timo"
<timo@.anonymous.com> wrote:

>Sue,
>Thanks for the reply. It doesn't appear to be Cross DB Ownership chaining;
>same issue after this:
>EXEC sp_configure 'Cross DB Ownership Chaining', '0'; RECONFIGURE
>EXEC sp_dboption 'DB1', 'db chaining', 'ON'
>EXEC sp_dboption 'DB2', 'db chaining', 'ON'
>Trace shows the procedure being invoked; the IN parameter is there, but all
>the OUT parameters are null. When I've encountered similar symptoms in Trac
e
>before, it was because the user lacked execute privileges on the procedure.
>But JOE has these privileges by virtue of membership in a db role.
>Any other way to troubleshoot this scenario using Trace?
>Thanks again.
>Timo
>
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:vcil70hj0j37239l9ds5tevbtfotc6n506@.
4ax.com...
>and
>which
>this:
>speak.
>is
>on
>when
>|||To add to Sue's response, if your objects are owned by 'dbo', the database
owners need to be the same in order to maintain an unbroken ownership chain
for dbo-owned objects. If needed, you can use sp_changedbowner to ensure
the databases are owned by the same login:
USE DB1
EXEC sp_changedbowner 'MyOwnerLogin'
USE DB2
EXEC sp_changedbowner 'MyOwnerLogin'
Users will need access to both databases but permissions on indirectly
referenced objects are not needed.
Hope this helps.
Dan Guzman
SQL Server MVP
"Timo" <timo@.anonymous.com> wrote in message
news:%23t2AiVLIEHA.580@.TK2MSFTNGP12.phx.gbl...
> Sue,
> Thanks for the reply. It doesn't appear to be Cross DB Ownership
chaining;
> same issue after this:
> EXEC sp_configure 'Cross DB Ownership Chaining', '0'; RECONFIGURE
> EXEC sp_dboption 'DB1', 'db chaining', 'ON'
> EXEC sp_dboption 'DB2', 'db chaining', 'ON'
> Trace shows the procedure being invoked; the IN parameter is there, but
all
> the OUT parameters are null. When I've encountered similar symptoms in
Trace
> before, it was because the user lacked execute privileges on the
procedure.
> But JOE has these privileges by virtue of membership in a db role.
> Any other way to troubleshoot this scenario using Trace?
> Thanks again.
> Timo
>
> "Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:vcil70hj0j37239l9ds5tevbtfotc6n506@.
4ax.com...
> and
with
on
> which
> this:
The
> speak.
> is
fine
> on
> when
has
>|||Thank you Dan for the dbchangeowner tip, and Sue for the Errors and Warnings
event class tip. I will use them to advantage. In Trace, I was not seeing
the completion of the sp, only the starting event, and so was unable to
determine what database the client was pointing at. After having the
developer re-check the connection string in the client-side code, we found
that the wrong database was being specified as the initial catalog.
Timo
"Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
news:ukvyQdVIEHA.2972@.TK2MSFTNGP12.phx.gbl...
> To add to Sue's response, if your objects are owned by 'dbo', the database
> owners need to be the same in order to maintain an unbroken ownership
chain
> for dbo-owned objects. If needed, you can use sp_changedbowner to ensure
> the databases are owned by the same login:
> USE DB1
> EXEC sp_changedbowner 'MyOwnerLogin'
> USE DB2
> EXEC sp_changedbowner 'MyOwnerLogin'
> Users will need access to both databases but permissions on indirectly
> referenced objects are not needed.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Timo" <timo@.anonymous.com> wrote in message
> news:%23t2AiVLIEHA.580@.TK2MSFTNGP12.phx.gbl...
> chaining;
> all
> Trace
> procedure.
DB#1
> with
> on
double
see
> The
it
> fine
role)
> has
>