Yesterday I was trying to restore the Web-application from fresh SQL-backup of database of production server. Doing that I used the algorithm described in one of my previous post “How to Restore a SharePoint Site from a Database Backup”. I restored backup into a new database, then I tried to create a new Web-application connected to the restored database, however, the undertaking failed, because I received the following error:
The specified SPContentDatabase Name=WSS_CONTENT_PROD Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.
According to the error some update has been deployed on the production server and has led to the version increase. The obvious solution was to upgrade the local environment. First of all, I went to Central Administration->Operations->Servers in Farm and found out the local current version of SharePoint, it was 184.108.40.20604.
In the same time the current version on production was 220.127.116.1110. By means of the page “How To find the SharePoint version” I discovered the cumulative update I should have set up to bring local version to production version. I downloaded the required update and installed. Unfortunately, despite the successful installation, the local version didn’t change at all and the error still remained during a new Web-application creation. When the standard steps don’t help, we need a trick. I tried to find where the restored database contains the information about version. The table Versions struck my eye:
SELECT [VersionId] ,[Version] ,[Id] ,[UserName] ,[TimeStamp] ,[FinalizeTimeStamp] ,[Mode] ,[ModeStack] ,[Updates] ,[Notes] FROM [WSS_CONTENT_PROD].[dbo].[Versions]
As you can see, we have one record where version is greater than local version (18.104.22.16810 > 22.214.171.12404). I replaced 126.96.36.19910 with 188.8.131.5204 using the following sql-command:
Update [WSS_CONTENT_PROD].[dbo].[Versions] SET [Version] = '184.108.40.20604' where [Version] = '220.127.116.1110'
After this trick I was able to create a new Web-application connected to the restored database without errors. Of course, Microsoft doesn’t welcome any handmade changes in content database and you should avoid doing them, but if you don’t have a choice you can attempt at your own risk In my case it has saved much time and life energy for me