Skip to content
Microsoft SQL Server

SQL Server Error 942

Database cannot be opened because it is offline

Applies to: All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance
Last technically reviewed 24 October 2026 on SQL Server 2025 (17.0.1145.4)
The full message
Msg 942, Level 14, State 4, Line 1
Database 'AppDb' cannot be opened because it is offline.
Other forms of this message
Connecting with the offline database as the initial database (sqlcmd -d, ODBC Driver 18, reproduced on SQL Server 2025)
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'CONTOSO\appuser'..
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Cannot open database "AppDb" requested by the login. The login failed..
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
Last reviewed
24 October 2026

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';
What to look for

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';
What to look for

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');
What to look for

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 state

Once 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 side

If 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 state

When 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;
Result
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.

Still stuck on a SQL Server error?

Browse the full SQL Server error library, or get hands-on help from an experienced SQL professional.