I\'ve got a stored procedure that allows an IN parameter specify what database to use. I then use a pre-decided table in that database for a query. The problem I\'m having i
I think Mark Brittingham has the right idea (here:
http://stackoverflow.com/questions/688425/evaluate-in-t-sql/718223#718223), which is to issue a use database command and write the sp to NOT fully qualify the table name. As he notes, this will act on tables in the login's current database.
Let me add a few possible elaborations:
From a comment by the OP, I gather the database is changed once a month, when it gets "too large". ("We have to load data into a new database each month or else it gets too large. – d03boy")
User logins have a default database, set with sp_defaultdb (deprecated) or ALTER LOGIN. If each month you move on to the new database, and don't need to run the sp on the older copies, just change the login's default db monthly, and again, don't fully qualify the table name.
The database to use can be set in the client login:
sqlcmd -U login_id -P password -d db_name, then exec the sp from there.
You can establish a connection to the database using the client of your choice (command line, ODBC, JDBC), then issue a use database command, the exec the sp.
use database bar; exec sp_foo;
Once the database has been set using one of the above, you have three choices for executing the stored procedure:
You could just copy the sp along with the database, in to the new database. As long as the table name is NOT fully qualified, you'll operate on the new database's table.
exec sp_foo;
You could install the single canonical copy of the sp in its own database, call it procs, with the tablename not fully qualified, and then call its fuly qualified name:
exec procs.dbo.sp_foo;
You could, in each individual database, install a stub sp_foo that execs the fully qualified name of the real sp, and then exec sp_foo without qualifying it. The stub will be called, and it will call the real procedure in procs. (Unfortunately, use database dbname cannot be executed from within an sp.)
--sp_foo stub: create proc bar.dbo.sp_foo @parm int as begin exec procs.dbo.sp_foo @parm; end go
However this is done, if the database is being changed, the real sp should be created with the WITH RECOMPILE option, otherwise it'll cache an execution plan for the wrong table. The stub of course doesn't need this.