- Error number
- 3702
- Severity
- 16 (user-correctable error)
- State
- 3 (your own session is in the database) or 4 (other sessions are using it)
- 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
- 23 October 2026
On this page
What it means
Error 3702 means DROP DATABASE was refused because at least one session, possibly your own, is still connected to that database.
SQL Server can only drop a database that nobody is using. Any session whose current database is the one being dropped holds a shared lock on it. On SQL Server 2025 in our lab, DROP DATABASE waited about 20 seconds for other sessions to leave (if they disconnected in time, the drop simply succeeded) and then failed with 3702 state 4. The session can be idle: an open query window in SSMS, a pooled application connection, a SQL Server Agent job or a monitoring tool all count.
The most common surprise is your own connection. If the query window that runs DROP DATABASE is itself connected to that database (the database drop-down in SSMS shows it), the drop fails immediately with state 3. Switch to master first.
Common causes
- Your own session is still using the database: the query window was opened on it, or the script ran
USE AppDbearlier. - Another query window, Object Explorer node or tool (SSMS, Azure Data Studio, a report) is connected to it.
- An application connection pool keeps idle connections open to the database.
- A SQL Server Agent job, replication agent or monitoring tool is running in it.
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.
Who is connected to the database?
SELECT session_id, login_name, host_name, program_name, status, last_request_end_time
FROM sys.dm_exec_sessions
WHERE database_id = DB_ID(N'AppDb');Every session whose current database is the one you are dropping, with the program and host so you can ask its owner to disconnect. Your own session appears here if you are still in that database.
Which sessions hold a lock on the database?
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');Sessions holding the shared database lock that blocks the drop, including ones whose current database is elsewhere but that are running a query in this one.
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.
Switch your own session to master
Client or network sideRun the drop from master, not from the database being dropped. In SSMS, also close other query windows connected to that database.
Caution: DROP DATABASE deletes the database and its data and log files. Make sure you have the right database and a backup if you might need it again.
USE master;
GO
DROP DATABASE AppDb;Ask the other users or applications to disconnect
Client or network sideUse the first diagnostic to find the program and host. Stop the application or job, or close the tool, then retry the drop. This is the safe route on a shared or production server.
Force everyone off with SINGLE_USER, then drop
Changes database stateWhen you are certain the database should go and nobody needs their open work, SINGLE_USER WITH ROLLBACK IMMEDIATE disconnects all other sessions and rolls back their open transactions. Run the drop straight after in the same session, from master, so no other connection takes the single slot. (This is what the SSMS option "Close existing connections" does.)
Caution: WITH ROLLBACK IMMEDIATE ends every other session in the database without warning and rolls back their uncommitted work. If another connection grabs the single user slot first, your own statements fail; run both statements together from master.
USE master;
GO
ALTER DATABASE AppDb SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE AppDb;Examples
Dropping a database another session is using
Two sessions at once. The DROP waited about 20 seconds for session 1 to disconnect before it failed.
-- Session 1 is connected to AppDb (for example an open query window).
-- Session 2:
USE master;
DROP DATABASE AppDb;Msg 3702, Level 16, State 4, Line 4 Cannot drop database "AppDb" because it is currently in use.
Reproduced on SQL Server 2025 (17.0.1145.4), 23 October 2026.
Dropping the database your own session is using
-- This query window is connected to AppDb
DROP DATABASE AppDb;Msg 3702, Level 16, State 3, Line 2 Cannot drop database "AppDb" because it is currently in use.
Reproduced on SQL Server 2025 (17.0.1145.4), 23 October 2026.
How to prevent it
Write teardown scripts that start with USE master, and close connection pools or stop the application before dropping a database it uses. For test environments that are rebuilt often, a SINGLE_USER WITH ROLLBACK IMMEDIATE step in the script is acceptable because nothing there needs protecting.
On shared servers, check sys.dm_exec_sessions first and talk to the owners of the connections: forcing sessions off is quick, but it rolls back their work.
Common questions
Why does DROP DATABASE fail when nobody else is connected?
Usually your own session is the user: the query window is connected to that database. Run USE master first, and check Object Explorer and other open windows.
Is setting the database OFFLINE a good way to drop it?
It also disconnects users, but dropping an offline database does not delete its data and log files from disk, so they are left behind. Use SINGLE_USER WITH ROLLBACK IMMEDIATE if you must force the drop.
Can I just KILL the sessions?
You can, but new connections may arrive before the drop runs. SINGLE_USER WITH ROLLBACK IMMEDIATE followed by the drop in the same session is more reliable, and has the same effect on the other users.
Learn more on CodeWithSQL
Official documentation
Last technically reviewed 23 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.