CURRENT_USER returns the name of the SQL Server database principal executing the statement.
CURRENT_USER returns the database user name that SQL Server maps to the current execution context. It reflects EXECUTE AS impersonation, making it ideal for auditing and row-level security.
Run SELECT CURRENT_USER;
in any query window. The function is parameter-less, so parentheses are not required. The result is a single-row, single-column result set containing the user name.
SESSION_USER shows the login at connection time, ignoring EXECUTE AS. CURRENT_USER respects impersonation, so use it inside stored procedures, triggers, or dynamic SQL where context can switch.
Typical cases include auditing which database principal touched data, enforcing row-level security predicates, tagging rows with the creator, and validating permissions inside stored procedures.
The keyword stands alone; no schema prefix, brackets, or parentheses are needed. Combine it with computed columns, variables, filters, or INSERT statements.
CURRENT_USER
Add a created_by
column to tables like Orders
. Insert rows with CURRENT_USER
so you always know which service account or analyst created the order record.
Always qualify permissions with schema names to avoid broken ownership chains. Pair CURRENT_USER with ORIGINAL_LOGIN()
for complete audit trails. Avoid caching the value in variables unless absolutely necessary.
Using SESSION_USER when EXECUTE AS is active. Replace with CURRENT_USER to capture impersonated principals.
Casting CURRENT_USER to INT. The value is varchar. Keep it as text or join against sys.database_principals
for IDs.
SESSION_USER, ORIGINAL_LOGIN(), USER_NAME(), SUSER_NAME()
No. Use it exactly as CURRENT_USER
.
Yes. It returns the principal specified in EXECUTE AS, making it safer for auditing context.
Yes, but the constraint fires under the caller’s context. Ensure that is the desired behavior when using impersonation.