Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've manually attached the data and log files I received from a client to a SQL Server 2005 Express SP3 database. During the upgrade to SP4, I get the following error:

The database 'MyDatabase' cannot be opened because it is version 622. This server support version 612 and earlier. A downgrade path is not supported.

Does anyone know what database version 622 is and how I can install it? This database is from a Canadian customer so maybe it comes from an international version of SQL Server. I really wish there was a reference for the database versions so I knew what 622 is. Much Googling resulted in much frustration and no answers.

Adding some more information. The original database was corrupt. I was only able to restore it using a backup. The data files were a little newer (2 days) so we were seeing if we could use those as well.

Upgraded from SQL Server 2005 Express to SQL Server 2008 Express successfully while the corrupt database was attached. SELECT @@VERSION reports Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (Intel X86). I ran sp_resetstatus, SET EMERGENCY and DBCC CHECKDB and received the following:

Msg 946, Level 14, State 1, Line 1
Cannot open database 'MyDatabase' version 622. Upgrade the database to the latest version.

share|improve this question
refer to How to determine the database version of an MDF file adn find out your SQL server version. Or you can do a restore headeronly and find it out if you have backup. – Kin Jan 16 '14 at 22:00
Seems to be some intermediate version number:… – a_horse_with_no_name Jan 16 '14 at 22:01
What does SELECT @@version; show in your server (and in the client's if possible to check)? – ypercubeᵀᴹ Jan 16 '14 at 22:05
@AaronBertrand: 612 is SQL 2005 with Vardecimal support enabled. All 2005 post SP2 will report 'highest supported' as 612, not 611 as 2005 RTM does. – Remus Rusanu Jan 17 '14 at 9:27
@Remus ah yes, I forgot that that setting changed the database version, thanks. – Aaron Bertrand Jan 17 '14 at 14:03

622 is an internal intermediate version, never released. How come you have an 622 version DB? The explanation is simple actually: an aborted upgrade. Look at the sequence Aaron posted:

Converting database 'x' from version 611 to the current version 655. 
Database 'x' running the upgrade step from version 611 to version 621. 
Database 'x' running the upgrade step from version 621 to version 622. 
Database 'x' running the upgrade step from version 622 to version 625.

If the last step above crashes, your database is a version 622 now (each step commits). This version can only be attached to a SQL Server 2008 (or newer) to continue and finish the upgrade. It seems to me you had a SQL Server 2005 DB (v. 611) you attached to a SQL Server 2008 or higher, it started to upgrade but the upgrade failed at step 622->625 and now you're trying to attach it back to the SQL 2005 instance. It can't be re-attached, your only chance is to try to move forward. If the upgrade continue to fail, you will have to start again from an original SQL 2005 database (a copy of the files, a backup...).

Why would a database upgrade fail? Same reason any operation can fail: CTRL-C, power outage, corrupted original database, hardware problems, bugs in the product. Knowing what the upgrade step 622-625 does, my moneys are on a corrupted source DB. Recovering from a failed upgrade is a bit more tricky. As usual, having a good, tested, backup and restore strategy pays off.

share|improve this answer
How many moneys, exactly? :-) – Aaron Bertrand Jan 17 '14 at 17:55
@AaronBertrand: it is intentionally misspelled :) I have a weird sense of humour, many not even consider it humor... – Remus Rusanu Jan 17 '14 at 18:15

622 is quite likely a very early beta or unreleased interim build of SQL Server 2008. Here is why I believe this is true. I have the highest possible build of SQL Server 2005 SP4:

Microsoft SQL Server 2005 - 9.00.5324.00 (X64) 
  Aug 24 2012 18:28:47 
  Copyright (c) 1988-2005 Microsoft Corporation
  Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)

That is 2005 + SP4 + CU3 + QFE from Security Bulletin MS12-070.

When I back the database up from 2005 SP4, and restore it on the very first RTM build of 2008:

Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) 
  Jul  9 2008 14:17:44 
  Copyright (c) 1988-2008 Microsoft Corporation
  Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

I get the following database version messages during the restore:

Converting database 'x' from version 611 to the current version 655.
Database 'x' running the upgrade step from version 611 to version 621.
Database 'x' running the upgrade step from version 621 to version 622.
Database 'x' running the upgrade step from version 622 to version 625.
Database 'x' running the upgrade step from version 625 to version 626.
... 25 steps removed ...
Database 'x' running the upgrade step from version 651 to version 652.
Database 'x' running the upgrade step from version 652 to version 653.
Database 'x' running the upgrade step from version 653 to version 654.
Database 'x' running the upgrade step from version 654 to version 655.

You'll notice that 622 is the second of many, many steps on the path between any 2005 build and the very first official, public build of 2008. Since there are no CTPs or interim builds at the end of a release cycle, this leads me to believe that this was a very early build in the beginning of the 2008 release cycle.

What is much more mysterious is how you have an instance of SQL Server 2008 that thinks it is version 612 (which, as Remus rightly reminded us, is 2005 with the vardecimal option enabled), while @@VERSION - at least according to the question - returns 10.0.1600.22 (which is 2008 RTM). I suspect you are attempting the restore and running SELECT @@VERSION; on two different servers.

I would suggest you apply Service Pack 3 and Cumulative Update 14, and then try restoring your database to the 2008 server again. This should bring your database version up to 655 (or 662/663 if you enable 15K partition support), and at that point you should be able to restore your database with the 622 version no problem (as long as it didn't become corrupt during some botched upgrade, as Remus suggested).

Where do you get your builds of SQL Server? And why are you running x86? It's 2014. Is the underlying operating system really 32-bit?

share|improve this answer

Simply put, your database comes from a more recent version of SQL Server then you are trying to attach it to and SQL Server does not support this. You can only attach databases to the same or newer versions of SQL Server than you got it from.

If you simply need to access the database and it isn't larger than 10GB, you can download SQL Server Express and attach the database to this. Note, this will upgrade the database to that version, so I would recommend making a backup of those files. IF your database is larger than 10GB, you will need SQL Server Standard, Enterprise, or Developer to attach it to.

share|improve this answer
Since the 2008 versions have an internal version number of 661, what version could that server be? Some promotional (CTP ?) version before the 2008 RTM one? – ypercubeᵀᴹ Jan 16 '14 at 22:29
If I had to venture a guess, 2005 SP4. But that's really just a guess – Mike Fal Jan 16 '14 at 22:41
2008 is 655; 2008 R2 is 661 (unless you enable 15K partition support, and then it can be 662 or 663, depending on the original source of the database). – Aaron Bertrand Jan 17 '14 at 2:55
@AaronBertrand Oops, thnx for the correction. – ypercubeᵀᴹ Jan 17 '14 at 10:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.