SQL Server Error 945

Error number

945

Severity

14 (user-correctable error)

State

2

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

What it means

Error 945 means SQL Server knows the database but could not start it, usually because one of its data or log files is missing, moved, locked or not readable by the service account, so the database sits in the RECOVERY_PENDING state.

When SQL Server starts a database (at service startup, after ALTER DATABASE ... SET ONLINE, or after an attach) it must open every file listed for it in sys.master_files. If a file cannot be opened, or there is not enough memory or disk space to start recovery, the database is left in RECOVERY_PENDING, and every later attempt to use it (USE, a query, a login whose default database it is) fails with 945 at severity 14.

The message itself never names the file or the cause. The real reason was logged when the database tried to start: look in the SQL Server error log just before the first 945 for errors such as 5120 or 17204 with an operating system error (2 means the file is not there, 3 the folder is not there, 5 access is denied, 32 the file is locked by another process). That earlier message decides the fix.

Common causes

• A data or log file was moved, renamed or deleted while the service was stopped or the database was offline, so the path in the catalogue no longer exists (OS error 2 or 3).
• The SQL Server service account lost permission on the file or folder, for example after files were copied in from elsewhere or the service account was changed outside SQL Server Configuration Manager (OS error 5).
• The drive or SAN volume holding the files was not available when SQL Server started, for example a disk that comes online after the service.
• Another process, such as a backup agent, antivirus scanner or a second instance, held the file open (OS error 32).
• The disk was full or the server was short of memory when recovery had to run.

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, state_desc, user_access_desc
FROM sys.databases
WHERE state_desc <> 'ONLINE';

SELECT file_id, type_desc, name AS logical_name, physical_name, state_desc
FROM sys.master_files
WHERE database_id = DB_ID(N'AppDb');

EXEC sp_readerrorlog 0, 1, N'AppDb';
EXEC sp_readerrorlog 0, 1, N'Operating system error';

SELECT servicename, service_account
FROM sys.dm_server_services;

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.

ALTER DATABASE AppDb SET ONLINE;

ALTER DATABASE AppDb MODIFY FILE (NAME = AppDb, FILENAME = N'E:\SqlData\AppDb.mdf');
ALTER DATABASE AppDb SET ONLINE;

RESTORE DATABASE AppDb
FROM DISK = N'D:\Backups\AppDb_full.bak'
WITH NORECOVERY, REPLACE;
-- RESTORE LOG ... WITH NORECOVERY for each log backup, then:
RESTORE DATABASE AppDb WITH RECOVERY;

Examples

A database whose data file path no longer exists

A throwaway database is taken offline and pointed at a file that does not exist, which is what happens when a file is moved or deleted. The SET ONLINE errors (5120, 5181, 5069, shown in the variants) are caught so the output shows the 945 that every later query receives. The last batch puts the real path back so the database starts again.

USE master;
-- Remember where the data file really is
SELECT name, physical_name INTO #real FROM sys.master_files
WHERE database_id = DB_ID(N'AppDb') AND type_desc = N'ROWS';

-- Simulate a moved file: take the database offline and point it at a file that does not exist
ALTER DATABASE AppDb SET OFFLINE WITH ROLLBACK IMMEDIATE;
ALTER DATABASE AppDb MODIFY FILE (NAME = AppDb, FILENAME = N'C:\Users\Public\AppDb_moved.mdf');
BEGIN TRY ALTER DATABASE AppDb SET ONLINE; END TRY BEGIN CATCH END CATCH;  -- fails: file not found
GO
USE AppDb;   -- any use of the database now fails
GO
SELECT state_desc FROM sys.databases WHERE name = N'AppDb';
GO
-- Fix: point the catalogue back at the real file and start the database
DECLARE @sql nvarchar(max) = (SELECT N'ALTER DATABASE AppDb MODIFY FILE (NAME = ' + QUOTENAME(name)
    + N', FILENAME = N''' + physical_name + N''');' FROM #real);
EXEC (@sql);
ALTER DATABASE AppDb SET ONLINE;
SELECT state_desc FROM sys.databases WHERE name = N'AppDb';

Msg 945, Level 14, State 2, Line 1
Database 'AppDb' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.

state_desc
RECOVERY_PENDING

The file "AppDb" has been modified in the system catalog. The new path will be used the next time the database is started.
state_desc
ONLINE

How to prevent it

Move database files only with the documented procedure: ALTER DATABASE ... MODIFY FILE first, then take the database offline, move the files, check their permissions and bring it online. Do not rename or move files under a running instance, and keep antivirus and backup agents away from live .mdf, .ndf and .ldf files.

Make sure the volumes that hold database files are available before the SQL Server service starts, and alert on databases whose state_desc is not ONLINE so a RECOVERY_PENDING database is noticed before users report it.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• MSSQLSERVER_945 (Microsoft Learn)
• Database states
• Move user databases

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.