SQL Server Error 5173

Error number

5173

Severity

16 (user-correctable error)

State

6

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 5173 means a file you asked SQL Server to use with a database (usually the log or an .ndf in an attach) belongs to a different database, or to a different point in time of the same one, so SQL Server refuses to put them together.

Every database file carries the identity of the database it belongs to, and the primary data file (.mdf) records which other files belong with it. When you attach files, SQL Server compares each listed file with the primary file. If one of them was created for another database, or comes from another copy of the same database, the attach stops with 5173 and then 1802, and nothing is attached. SQL Server is protecting you: a data file combined with the wrong log would come up inconsistent.

The message does not say which file is wrong. Check the files you listed after the .mdf: the log file is the usual suspect, especially when several databases have similar file names or copies of the same database exist in different folders. On an existing database the same check can fail at startup, which the message warns may mean a damaged file.

Common causes

• The attach lists the log (or an .ndf) of another database, for example after files were copied into one folder and similar names were mixed up.
• The log file comes from another copy of the same database, such as an older copy or a copy from a test server, instead of the file detached with this .mdf.
• Files were copied while the database was online, so the data and log copies do not belong together.
• A file of an existing database was replaced on disk, or is damaged, so it no longer matches the primary file at startup.

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 DB_NAME(database_id) AS database_name, file_id, type_desc, name AS logical_name, physical_name
FROM sys.master_files
ORDER BY physical_name;

EXEC sp_readerrorlog 0, 1, N'do not match the primary file';
EXEC sp_readerrorlog 0, 1, N'AppDb';

SELECT TOP (5) bs.database_name, bs.backup_finish_date, bf.file_type, bf.logical_name, bf.physical_name
FROM msdb.dbo.backupset AS bs
JOIN msdb.dbo.backupfile AS bf ON bf.backup_set_id = bs.backup_set_id
WHERE bs.database_name = N'AppDb'
ORDER BY bs.backup_finish_date DESC;

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;

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

Attaching a data file with the log of another database

Two throwaway databases, AppDb and cws_errlab_other, are detached; AppDb's data file is then attached with cws_errlab_other's log. The fix attaches each database with its own files, and the second database is dropped at the end.

USE master;
CREATE DATABASE cws_errlab_other;   -- a second database
GO
DECLARE @mdf nvarchar(260), @ldf nvarchar(260), @mdf2 nvarchar(260), @ldf2 nvarchar(260), @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 FROM sys.master_files WHERE database_id = DB_ID(N'AppDb') AND type_desc = N'LOG';
SELECT @mdf2 = physical_name FROM sys.master_files WHERE database_id = DB_ID(N'cws_errlab_other') AND type_desc = N'ROWS';
SELECT @ldf2 = physical_name FROM sys.master_files WHERE database_id = DB_ID(N'cws_errlab_other') AND type_desc = N'LOG';
EXEC sp_detach_db N'AppDb';
EXEC sp_detach_db N'cws_errlab_other';

-- AppDb's data file with the OTHER database's log
SET @sql = N'CREATE DATABASE AppDb ON (FILENAME = N''' + @mdf + N'''), (FILENAME = N''' + @ldf2 + N''') FOR ATTACH;';
EXEC (@sql);

-- Fix: attach each database with its own files
SET @sql = N'CREATE DATABASE AppDb ON (FILENAME = N''' + @mdf + N'''), (FILENAME = N''' + @ldf + N''') FOR ATTACH;'
    + N'CREATE DATABASE cws_errlab_other ON (FILENAME = N''' + @mdf2 + N'''), (FILENAME = N''' + @ldf2 + N''') FOR ATTACH;';
EXEC (@sql);
GO
DROP DATABASE cws_errlab_other;

Msg 5173, Level 16, State 6, Line 1
One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files.  If this is an existing database, the file may be corrupted and should be restored from a backup.
Msg 1802, Level 16, State 7, Line 1
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

How to prevent it

Keep each database's files in a folder or naming scheme that makes their owner obvious (AppDb.mdf with AppDb_log.ldf), and copy all files of a database together after a clean detach. Never mix files from different copies of the same database.

Prefer BACKUP and RESTORE for moving or copying databases: a backup is one consistent unit, so data and log can never be paired wrongly.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• Attach a database
• Detach a database
• Database engine errors 5000 to 5999

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.