- Error number
- 942
- Severity
- 14 (user-correctable error)
- State
- 4
- 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
On this page
What it means
Error 942 means the database exists but someone has taken it OFFLINE, so SQL Server will not open it for any query until it is brought ONLINE again.
OFFLINE is a state an administrator chooses with ALTER DATABASE ... SET OFFLINE (or Tasks, Take Offline in SSMS). The database stays registered on the instance, but its files are closed and nobody can use it. Any statement that needs it, such as USE AppDb or a three-part name AppDb.dbo.Orders, fails with 942 at severity 14. A connection that names the database as its initial database fails at login with error 4060 instead.
Unlike 945 or 926, nothing is wrong with the database: it was switched off on purpose, often for maintenance, file moves or before retiring it. The real question is who took it offline and whether it should come back. The error log records each state change.
Common causes
- An administrator took the database offline for maintenance, a file move or a storage change and did not bring it back.
- The database is being retired: it was taken offline as a last check before dropping it, and an application or job still uses it.
- A script or deployment tool runs SET OFFLINE (for example before restoring or copying files) and stopped before the SET ONLINE step.
- A query, view, synonym or linked server still refers to the database by name with a three-part name.
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.
Which databases are offline?
SELECT name, state_desc, user_access_desc, is_read_only
FROM sys.databases
WHERE state_desc <> 'ONLINE'; The database shows OFFLINE. Other states (RECOVERY_PENDING, SUSPECT, RESTORING) are different problems with their own errors.
Who took it offline, and when?
EXEC sp_readerrorlog 0, 1, N'OFFLINE';
EXEC sp_readerrorlog 0, 1, N'AppDb'; An entry such as Setting database option OFFLINE to ON for database 'AppDb' with its time and session id. Use it to find the person or job before bringing the database back.
Are the files still where SQL Server expects them?
SELECT type_desc, name AS logical_name, physical_name, state_desc
FROM sys.master_files
WHERE database_id = DB_ID(N'AppDb'); The paths SQL Server will open when the database comes online. If files were moved while it was offline, the catalogue must be updated first (see error 945), or SET ONLINE fails.
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.
Bring the database online
Changes database stateOnce you know it is meant to be used again, bring it online. SQL Server opens the files and runs recovery; it is usable straight after.
Caution: Check with whoever took it offline first: it may be offline on purpose (files being moved or copied, or about to be dropped). If its files were moved, fix the paths before SET ONLINE.
ALTER DATABASE AppDb SET ONLINE;
Point the application at the right database
Client or network sideIf the database is retired on purpose, change the connection string, job step, synonym or three-part names that still use it, rather than bringing it back.
Use a scripted, reversible offline step
Changes database stateWhen maintenance needs the database offline, script both steps together and check the state at the end, so a failure in between is visible.
Caution: WITH ROLLBACK IMMEDIATE disconnects every user and rolls back their open transactions. Dropping a database while it is offline leaves its files on disk, so bring it online before DROP DATABASE.
ALTER DATABASE AppDb SET OFFLINE WITH ROLLBACK IMMEDIATE;
-- ... maintenance ...
ALTER DATABASE AppDb SET ONLINE;
SELECT state_desc FROM sys.databases WHERE name = N'AppDb';
Examples
Using a database that was taken offline
USE master;
ALTER DATABASE AppDb SET OFFLINE WITH ROLLBACK IMMEDIATE;
GO
USE AppDb;
GO
-- Fix
ALTER DATABASE AppDb SET ONLINE;
Msg 942, Level 14, State 4, Line 1 Database 'AppDb' cannot be opened because it is offline.
Reproduced on SQL Server 2025 (17.0.1145.4), 23 October 2026.
How to prevent it
Treat taking a database offline as a change: record who did it and why, and set a reminder or job step to bring it back. Monitor sys.databases for databases that are not ONLINE.
When retiring a database, find its users first (connection strings, jobs, synonyms, linked servers) and keep a final backup before it goes offline and is dropped.
Common questions
Is my data lost when a database is offline?
No. The files are untouched and SQL Server still knows where they are. ALTER DATABASE ... SET ONLINE makes the database usable again, unless its files were moved or deleted in the meantime.
Why does my connection say "Cannot open database requested by the login" instead?
When the offline database is the initial database in the connection string, the login fails before any query runs, so the client reports 4060. Inside an open session, USE or a three-part name gives 942.
Can I see the tables of an offline database?
No. Its metadata lives inside its own files, which are closed. sys.databases and sys.master_files in master still list the database and its files.
Learn more on CodeWithSQL
Official documentation
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.