SQL Server Error 924

Error number

924

Severity

14 (user-correctable error)

State

1

Product

Microsoft SQL Server Database Engine

Versions

All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance

Category

Database State & Recovery

Last reviewed

24 October 2026

What it means

Error 924 means the database is in SINGLE_USER mode and its one allowed connection is already taken by another session, so yours cannot enter it.

SINGLE_USER mode allows exactly one session in the database. It is normally set for maintenance (ALTER DATABASE ... SET SINGLE_USER), and whichever session uses the database first after that holds the slot. Every other attempt, a USE statement, a three-part name or a query from Object Explorer, fails with 924 at severity 14. A new connection that names the database as its initial database fails at login (4060).

The holder is often not the person who set the mode: an application that reconnects automatically, a SQL Server Agent job, a monitoring tool or an SSMS Object Explorer node can grab the slot within seconds, which is why the DBA who ran SET SINGLE_USER suddenly cannot get back in. Find that session first.

Common causes

• Someone set the database to SINGLE_USER for maintenance (for example a restore, DBCC or a collation change) and another session took the only connection.
• An application with a connection pool or retry logic reconnected as soon as SINGLE_USER was set.
• A SQL Server Agent job, backup tool or monitoring agent connects to the database on a schedule.
• The database was left in SINGLE_USER after maintenance finished, and the session that set it is still open in another query window.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT name, user_access_desc, state_desc
FROM sys.databases
WHERE name = N'AppDb';

SELECT session_id, login_name, host_name, program_name, status, login_time, last_request_end_time
FROM sys.dm_exec_sessions
WHERE database_id = DB_ID(N'AppDb');

SELECT request_session_id, request_mode, request_status
FROM sys.dm_tran_locks
WHERE resource_type = 'DATABASE'
  AND resource_database_id = DB_ID(N'AppDb');

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

USE master;
ALTER DATABASE AppDb SET MULTI_USER WITH ROLLBACK IMMEDIATE;

USE master;
ALTER DATABASE AppDb SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
USE AppDb;
-- ... maintenance ...
USE master;
ALTER DATABASE AppDb SET MULTI_USER;

Examples

A second session tries to use a SINGLE_USER database

Two sessions at once. Session 1 sets SINGLE_USER from inside the database and so keeps the only slot; session 2 is refused.

-- Session 1 (in AppDb):
ALTER DATABASE AppDb SET SINGLE_USER;

-- Session 2, while session 1 is still connected:
USE AppDb;

Msg 924, Level 14, State 1, Line 1
Database 'AppDb' is already open and can only have one user at a time.

How to prevent it

Before setting SINGLE_USER, stop the applications, jobs and tools that use the database, and run the maintenance from one script that sets the mode, enters the database, does the work and sets MULTI_USER again.

For maintenance that only needs to keep ordinary users out, RESTRICTED_USER is often enough and still lets administrators in with more than one connection.

Common questions

Learn more on CodeWithSQL

• Transactions, locks and deadlocks

Official documentation

• Set a database to single-user mode
• ALTER DATABASE SET options (Transact-SQL)
• Database engine errors 0 to 999

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.