SQL Server Error 1813

Error number

1813

Severity

16 (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

24 October 2026

What it means

Error 1813 means CREATE DATABASE (usually FOR ATTACH) got as far as opening the files but could not start the new database, so it gave up; the real reason is always in the error printed just before it.

An attach runs in two stages. First SQL Server checks and opens every file you listed; if that fails you get the file error (5120, 5133, 5173) followed by 1802. If the files are accepted, SQL Server then tries to start the database: read the primary file, find or rebuild the transaction log and run recovery. When that second stage fails, the statement ends with 1813 and the database is not created.

So 1813 is a summary line, not a cause. Scroll up to the first message of the batch: in our lab it was 5170 (SQL Server wanted to build a new log file because the original one was missing, but a file of that name was already there), followed by a "File activation failure" line naming the log path it could not find. Other first errors you may meet are a version that this server cannot open, or a log that cannot be rebuilt because the database was not shut down cleanly. Fix that first error and the 1813 goes away.

Common causes

• The log file recorded in the data file is missing or was renamed, and SQL Server could not create a replacement (in our lab: a file with the default log name already existed, error 5170).
• Only the .mdf was attached, but the database was not shut down cleanly, so the log cannot be rebuilt without losing transactions (documented for FOR ATTACH_REBUILD_LOG).
• The files come from a newer version of SQL Server than the instance you are attaching them to; an attach cannot downgrade a database.
• Recovery of the attached database failed because the data or log file is damaged.

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.

EXEC sp_readerrorlog 0, 1, N'AppDb';
EXEC sp_readerrorlog 0, 1, N'File activation failure';

SELECT DB_NAME(database_id) AS database_name, type_desc, physical_name, state_desc
FROM sys.master_files
WHERE DB_NAME(database_id) = N'AppDb'
   OR physical_name LIKE N'%AppDb%';

SELECT SERVERPROPERTY('ProductVersion') AS product_version,
       SERVERPROPERTY('ProductMajorVersion') AS major_version;

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.

CREATE DATABASE AppDb
ON (FILENAME = N'D:\SqlData\AppDb.mdf'),
   (FILENAME = N'D:\SqlData\AppDb_log.ldf')
FOR ATTACH;

CREATE DATABASE AppDb
ON (FILENAME = N'D:\SqlData\AppDb.mdf')
FOR ATTACH_REBUILD_LOG;

RESTORE DATABASE AppDb
FROM DISK = N'D:\Backups\AppDb_full.bak'
WITH RECOVERY;

Examples

Attaching a data file whose log is missing

The output starts with 5170 because 1813 always comes after the error that caused it; that order is the lesson. A throwaway database's log is pointed at a file that does not exist and the database is detached, which is what a lost .ldf looks like. Paths in the output are shortened to D:\SqlData. The last statement attaches the database again with its real log.

USE master;
DECLARE @mdf nvarchar(260), @ldf nvarchar(260), @log sysname, @sql nvarchar(max);
SELECT @mdf = physical_name FROM sys.master_files WHERE database_id = DB_ID(N'AppDb') AND type_desc = N'ROWS';
SELECT @ldf = physical_name, @log = name FROM sys.master_files WHERE database_id = DB_ID(N'AppDb') AND type_desc = N'LOG';

-- Simulate a lost log: record a log path that does not exist, then detach
SET @sql = N'ALTER DATABASE AppDb MODIFY FILE (NAME = ' + QUOTENAME(@log) + N', FILENAME = N''' + REPLACE(@ldf, N'_log.ldf', N'_lost.ldf') + N''');';
EXEC (@sql);
EXEC sp_detach_db N'AppDb';

-- Attach the data file alone
SET @sql = N'CREATE DATABASE AppDb ON (FILENAME = N''' + @mdf + N''') FOR ATTACH;';
EXEC (@sql);

-- Fix: list the real log file
SET @sql = N'CREATE DATABASE AppDb ON (FILENAME = N''' + @mdf + N'''), (FILENAME = N''' + @ldf + N''') FOR ATTACH;';
EXEC (@sql);
SELECT state_desc FROM sys.databases WHERE name = N'AppDb';

Msg 5170, Level 16, State 1, Line 1
Cannot create file 'D:\SqlData\AppDb_log.ldf' because it already exists. Change the file path or the file name, and retry the operation.
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'AppDb'. CREATE DATABASE is aborted.
File activation failure. The physical file name "D:\SqlData\AppDb_lost.ldf" may be incorrect.

How to prevent it

Move databases with BACKUP and RESTORE, or detach and copy every file together (data, log and any .ndf files) and attach them all in one statement. Keep the log files with the data files they belong to, and never rename an .ldf by hand.

Before attaching files from another server, check its version, and detach cleanly (sp_detach_db) rather than copying files from a running or crashed instance.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• CREATE DATABASE (Transact-SQL)
• Attach a database
• Database engine errors 1000 to 1999

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.