You can test this procedure by running the following code, which executes the procedure against Northwind and msdb:
USE Northwind
EXEC sp_getusertables
EXEC msdb..sp_getusertables
Note that you get different user tables for each database.
SQL Server always resolves special procedures that reference user objects against the master database. For example, first drop any tables called T1 in master, Northwind, and Pubs. Then, run the code that Listing 1 shows to create a table called T1 in the Northwind database and in the Pubs database and a special procedure that returns all rows from T1. Next, run the following code, which executes your procedure first in Northwind, then in Pubs:
EXEC Northwind..sp_getT1rows
EXEC pubs..sp_getT1rows
You get error messages stating that the object name T1 is invalid because SQL Server looks for the table only in master, as the following messages show:
Server: Msg 208, Level 16,
State 1, Procedure sp_getT1rows, Line 4
Invalid object name 'T1'.
Server: Msg 208, Level 16, State 1, Procedure sp_getT1rows, Line 4
Invalid object name 'T1'.
Apparently, a back door lets you force SQL Server to resolve user objects the same as it does system objectsnamely, in the context of the database you're connected to or the one you specify, if you do so explicitly. You mark the procedure as a system object by using the undocumented stored procedure sp_MS_marksystemobject:
USE master
EXEC sp_MS_marksystemobject sp_getT1rows
Now run the previous code snippet again:
EXEC Northwind..sp_getT1rows
EXEC pubs..sp_getT1rows
Prev. page
1
[2]
3
4
5
next page