Today I’ll be handling an issue I had with the migration of a SQL Server 2000 database to SQL Server 2012. About a week ago we migrated the database from the old and grumpy, and more importantly unsupported windows server 2003 and SQL Server 2005 instance. All was well, and we had no instant issues when users started working with the application. The migration was seamless and we did not expect any future problems, also the upgrade advisor did not give us any errors!
But then lightning struck this morning, somebody who was on a holiday came back into work and started working with the application on the migrated database. But apparently this user was a bit different than the other users who tested. This guy used the application to its full capacity, unravelling a waterfall of syntax errors & DB errors. The impact was uncontrollable so there was only one option, we had to fall back to the old & abandoned SQL Server 2000 instance.
Now here starts the tricky part, as users had been using the migrated database in production for several days, they had uploaded a lot of data which had to be present when we fell back to the SQL Server 2000 instance. But as you all know once a database is on SQL Server 2012, even in lower compatibility mode, it will not restore on a version lower than the running version! It is also not possible to detach and attach the database as there are changes which happened on system table level. Due to these restrictions there is only one option left, scripting out the database and exporting the data to the old SQL Server 2000 database.
I will now continue on explaining how I executed the fall back scenario.
First we will generate the scripts off the database
We choose to script out the entire database & all database objects! Watch out for triggers, these are not scripted out you will have to manually add them later!
Click next to create the scripts and copy them to clipboard/file/new query window whatever has your preference
And click next, it will now script out your database.
Execute the script on the destination server, here it was a SQL server 2005, you might get some errors for adding members & altering compatibility mode, depending on the SQL server version you are working with.
You can alter the statements to statements that work on your version. Also you might want to set your database owner to sa at this point.
Now that we have our database on our SQL Server 2005 we want to pump the data into it from the new old database J
Go to the database you want to export the data from and click export data.
Enter the information of your source database
Afterwards insert the information of the destination database
Then choose to copy data from table
In the next window select all your tables, and then check table by table by clicking edit mappings
Don’t forget to put on enable identity insert on the tables!!!
Also if you have foreign keys, don’t forget to disable them when loading your data between the instances, you can easily do that with this command.
— Disable all the constraint in database
EXEC sp_msforeachtable ‘ALTER TABLE ? NOCHECK CONSTRAINT all’
When you have done all the steps above you should be able to export your data to your SQL server 2000 database.
After you did the export don’t forget to re-enable your foreign keys
— Enable all the constraint in database
EXEC sp_msforeachtable ‘ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all’
In this way we just kind of restored a SQL Server 2012 database on a SQL Server 2005 instance! So the fall back was successful! All data was present and the business was happy, now we can start testing the application again for compatibility with the SQL Server 2012 version which will prove to be a long and though process!
But the application is working again to its full extent, unfortunately it is on a SQL Server 2005 instance with a compatibility mode of SQL Server 2000 with a Windows Server 2003. (unsupportedception J)
Hope you enjoyed reading this blog and stay tuned!