Error 948 and 946: The Database Was Created by a Newer SQL Server Version

Fix it now

Errors 948 and 946 mean the file or backup came from a newer build than this engine understands. 948’s published text ends with the sentence that settles it: a downgrade path is not supported. The honest choices are to open it on a version that can, or to move the data out row by row.

SELECT SERVERPROPERTY('ProductVersion') AS ThisServer, SERVERPROPERTY('ProductLevel') AS Level, SERVERPROPERTY('Edition') AS Edition;
RESTORE HEADERONLY FROM DISK = 'D:\path\file.bak';

1. Read the two numbers in the error message. 948 states the version the database is and the highest version this server supports; 3169 does the same for a backup. Those are internal database versions, not product version numbers, so do not try to match them against 15.0 or 16.0.
2. Establish what you are running, and whether any instance anywhere is at or above the version named.
3. If one exists, attach or restore there first, then move the data down with a script, an export, or an insert through a linked server.
4. If none exists, licensing and installing that version is the direct route: the file then attaches and upgrades in place during recovery.

Attaching a database to a newer instance upgrades its internal version irreversibly. Copy the files, or take a backup, before you attach anything you might need to put back.

If the database is online where you need it, you are done. If not, the next section explains why the file only moves one way.

Why it happens

Every database file records an internal version number describing the on-disk structures it uses, and an instance compares that number against what its own build understands. A newer engine knows how to read and upgrade older structures, so an older database attaches to a newer instance and is rewritten during recovery. An older engine has no knowledge of structures introduced after it shipped, so it refuses rather than guessing. 948 is that refusal for a data file and 3169 for a backup.

Microsoft’s own page for 948 names a mechanism people often miss: using an advanced feature on a newer release can raise the file’s version, so a database that nobody thinks of as having “moved” can still refuse to attach downlevel. Its example is the vardecimal storage format. The practical point is that the version in the message is a property of what was done to the database, not only of which server it last sat on.

The numbers in these messages are internal database versions and there is no Microsoft-published table mapping them to product releases. Do not try to translate them, and be wary of any list that claims to: the message already tells you the relationship you need, which is that this database is higher than this server supports. What you actually have to establish is which product version produced it, and the reliable way to do that is to ask whoever detached or backed it up, or to read the header of a backup with RESTORE HEADERONLY.

Compatibility level is a different thing entirely and is constantly confused with this. Setting it to an older value changes how the optimiser and some language features behave. It does not touch the file format and does not make the file readable by an older engine. A database restored from a newer server with its compatibility level turned down is still a newer file.

Full reference

Which message you have, and what it tells you

Reading a backup before you try to restore it

RESTORE HEADERONLY FROM DISK = 'D:\path\file.bak';

RESTORE FILELISTONLY FROM DISK = 'D:\path\file.bak';

RESTORE HEADERONLY returns a row per backup set on the device, including the version information that produced it and the database name. RESTORE FILELISTONLY returns the logical and physical file names, which is what you need if the target has a different drive layout. Neither touches an existing database, so both are safe to run on a production instance while you work out what you have.

Moving the data rather than the file

1. On the newer instance, script the schema for the objects you need. Include indexes, constraints and defaults; check what your tool omits by default.
2. Create the schema on the older instance and fix anything the older version cannot represent, which the script will tell you by failing.
3. Move the rows: the import and export wizard for a one-off, an SSIS package for something repeatable, or an INSERT … SELECT through a linked server for moderate volumes.
4. Recreate the objects that live outside the database: logins with their SIDs preserved, jobs, operators, linked servers and credentials.
5. Reconcile row counts per table, then run DBCC CHECKDB on the result and take a backup.

Why there is no downgrade tool

The structures inside the file are genuinely different between releases rather than merely labelled differently, which is why 948’s published text says flatly that a downgrade path is not supported. Anything offering to rewrite a header so an older engine will open the file is proposing to hand the engine structures it does not understand, and the failure mode is corruption discovered later rather than a refusal now. Do not run such a tool against data you care about.

Avoiding this next time

• Record the product version alongside every backup you archive. RESTORE HEADERONLY reads it back, but a note is faster.
• Keep at least one instance at the highest version you have ever used, even if only for reads.
• Take backups rather than copying loose .mdf and .ldf files. Backups carry integrity information and a header you can inspect.
• Before detaching anything, check where it is going. A detach followed by a failed attach is how most of these start.

Every code this article covers

Confirm the fix worked

1. The database shows ONLINE in sys.databases on the instance now hosting it.
2. SELECT SERVERPROPERTY('ProductVersion'); on that instance is at or above the version that produced the file.
3. Row counts on the largest tables match the source, if you moved the data rather than the file.
4. Logins resolve to database users rather than being orphaned, if you scripted them across.
5. Applications connect, a test write succeeds, and a fresh backup completes.

Questions people ask about this