We have been asked to move from SQL Server 2008 R2 over to 2012, the installation completed a few hours ago. Ever since I've been trying to attach databases from 2008 over to 2012.

It seems to be having no effect. Error messages below:

Attach database failed for Server 'Development\SQLSERVER'. (Microsoft.SqlServer.Smo)
Database 'PS_EmpData' cannot be upgraded because its non-release version (539) is not supported by this version of SQL Server. You cannot open a database that is incompatible with this version of sqlservr.exe. You must re-create the database.

I mean, this table is quite a big database; and the time it would take to re-create with all the inserts would be unreal. We are still operating with our SQL 2008 R2 for production, but development process is underway on 2012.

My overall question is, do we have to re-create the database to use 2012 or is there a work around?


The version (539) indicated in the error message says that this database is a Sql Server 2000 database and thus is not supported in Sql Server 2012 See here

Probably in your SqlServer 2008R2 this particular database has a compatibilty level set to Sql Server 2000. You could try to change this level going to the properties of the database, Options page and changing the compatibility level to 2008, then retry to attach the database to Sql Server 2012

| improve this answer | |

Things don't add up. Either the database is from SQL 2008, and then it would be version 655 (or 661 if is SQL Server 2008 R2), or the database is version 539 which is basically an antediluvian version. I would much rather believe the database version field is actually corrupted in the file (eg. it got changed in the file copy). Make sure the file is identical with the source file from your SQL 2008 instance.

| improve this answer | |
  • I kind of agree. If the 2000 database was attached / restored to the 2008 / 2008 R2 instance, its version should no longer be 539 (even if it is still in 80 / 2000 compatibility mode). I wonder if the source backup or mdf file from 2000, that was used to create the database on 2008 / 2008 R2, was also used to create the database on 2012 (as opposed to a backup or detached copy of the mdf file from 2008 / 2008 R2). It is also curious that it is an attach operation as opposed to a restore operation... – Aaron Bertrand Jan 23 '13 at 17:18

The 539 internal database version is from SQL 2000. 2012 likely doesn't support directly coming from that version - but, since you have a 2008 R2 server, you probably have some options for upgrading that db on that server first.

If you have enough space on the 2008 R2 server for another copy of the db, get one on there, then try setting the compatability level to 100 (2008 R2), then detach and re-attach. The upgrade of the internal database version generally happens during the attach (or a restore).

I happen to have 2000/2008R2/2012 all deployed, so I'm going to do a quick test and ensure the above works.

Edit: Taking a backup from my 2000 server and restoring to the 2008 R2 server automatically upgraded the internal database version to 661 (2008 R2), though the compatability level is set to 80 (SQL 2000). I'm not sure how you ended up with a v539 db on 2008 R2, but try the attach/detach on a copy of it after modifying the compatability level, and check the internal version using (from Jonathan Kehayias blog post here):

DBCC TRACEON (3604);  
DBCC PAGE (ExampleDB, 1, 9, 3); 

Somewhere in the output should be an indicator of the internal version number:

dbi_version = 655 
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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