How to get the name of the database a stored procedure is executed in within that stored procedure while it's executing?

Question

Weird question?...maybe, but I have a need. :)

I have a stored procedure that I want to use universally in any database. The stored procedure generates some dynamic SQL and then executes that SQL in a database that is passed in as one of the parameters in this procedure.

BUT I want to make the database parameter optional and when no database name is passed in, I want the dynamic SQL to execute within the same database that the procedure itself was called from. (Please keep in mind this procedure could be executed across databases and not within the same database that the procedure itself lives in.)

Answer 1

You can easily tell the dynamic SQL execute in a specific database by dynamically building a [database].sys.sp_executesql command:

USE your_database;
GO

CREATE PROCEDURE dbo.DatabaseNameOptional
    @db sysname = NULL
AS
BEGIN
  SET NOCOUNT ON;

  DECLARE @sql nvarchar(max) = N'SELECT DB_NAME(); /* other stuff */'

  DECLARE @exec nvarchar(770) = COALESCE(@db, DB_NAME())
    + N'.sys.sp_executesql';

  -- alternatively, just leave DB_NAME() out of it:

  --DECLARE @exec nvarchar(770) = COALESCE(@db, N'')
  --  + N'sys.sp_executesql';

  EXEC @exec @sql;
END
GO

Try it out:

USE your_database;
GO

EXEC dbo.DatabaseNameOptional;
GO  -- output = your_database

EXEC dbo.DatabaseNameOptional @db = N'master';
GO  -- output = master

USE tempdb;
GO

EXEC your_database.dbo.DatabaseNameOptional;
GO  -- output = your_database

EXEC your_database.dbo.DatabaseNameOptional @db = N'master';
GO  -- output = master

In the execution context of the procedure, though, no, I don't think there's any way to determine where the call originated from (or to run in that context). That's the benefit of using a system-marked procedure in master - if that's the functionality you want, you need to decide if "putting objects in master" is ickier than "not getting what I want."

Answer 2

I don't like creating procedures in master, but if you put your procedure in the master database and add the SP_ prefix like sp_dynamicproc, you could call it from inside your own user database and get the correct db_name() parameter.

Source

An example

USE master  
GO
CREATE PROCEDURE dbo.sp_dynamicproc
(@dbname nvarchar(255) = NULL)
as
BEGIN

DECLARE @SQL NVARCHAR(MAX)

IF @dbname IS NULL 
BEGIN
SET @dbname = (SELECT db_name());
END
SELECT db_name()
SET @SQL = 'SELECT * FROM '+QUOTENAME(@dbname)+'.INFORMATION_SCHEMA.COLUMNS ;';
EXEC(@SQL);

END

Calling the proc

USE test
GO
exec dbo.sp_dynamicproc;

Result

Answer 3

Why don't you create your own SQL Server System Stored Procedures?

It's a better solution than using dynamic SQL.

Answer 4

Say we have a database Utils with a procedure MyUtil and we do:

USE MyDatabase
GO
EXEC Utils.dbo.MyUtil
GO

then as per the original question we would like Utils.dbo.MyUtil to perform some utility operations inside MyDatabase, not inside Utils.

There seems to be no direct way to do exactly this. Accessing DB_NAME(), sys.sysprocesses or sys.dm_exec_sessions within Utils.dbo.MyUtil will always identify the current database as Utils regardless of where Utils.dbo.MyUtil was called from. On the other hand syslogins and sys.sql_logins return the login database, not the current database (e.g. as selected with USE xyz).

The problem is not that Utils.dbo.MyUtil can't do it's work, it's that it can't automatically work out where to do its work (i.e. it can't tell where it was called from), as we'd ideally like it do.

One option (still less than ideal, because it involves modifying master; this builds on and adds to the answers by @RandiVertongen and @DaniloBraga) is to provide a thin wrapper procedure in the master database:

USE master
GO
CREATE PROCEDURE sp_MyUtil
    {...other params}
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @default_db_name sysname = DB_NAME()

    EXEC Utils.dbo.MyUtil {...other params,} @default_db_name = @default_db_name
END
GO

USE Utils
GO
ALTER PROCEDURE MyUtil
    {...other params,}
    @default_db_name sysname = null
AS
BEGIN
    SET NOCOUNT ON;

    {...do stuff which uses @default_db_name to identify the calling DB, this is set correctly and passed automatically when sp_MyUtil is used}
END
GO

No you can call:

USE MyDatabase
GO
EXEC sp_MyUtil
GO

this ends up executing Utils.dbo.MyUtil, but now with enough information available to it for it to do its work in MyDatabase.

Bear in mind the strong recommendation (for security reasons) never to install modifications to the master database on a production server. Because these master procedures are only a convenience to enable the user to type less, you could always install the Utils database without the master wrapper procedures on the production server... if you needed to.