My development PC has SQL Server 2008. I have a database which is created and running on SQL Server 2008. Instance name of SQL Server 2008 is SQLEXPRESS that is default one. My connection string is something like:
<add name="DB1Entities"
connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string="data source=.\SQLEXPRESS;attachdbfilename=|DataDirectory|\DB1.mdf;integrated security=True;user instance=True;multipleactiveresultsets=True;App=EntityFramework""
providerName="System.Data.EntityClient" />
Working nicely on my development PC. But as I tried to run on another PC it's not working, but instead showing this error :
System.Data.EntityException: The underlying provider failed on Open. ---> System.Data.SqlClient.SqlException: The database '..\DB1.MDF' cannot be opened because it is version 655. This server supports version 612 and earlier. A downgrade path is not supported.
First my test PC has only SQL Server 2005 (instance name: SQLEXPRESS). Due to this error I have installed SQL Server 2008 (instance Name: MSSQLSERVER). I have tried many solutions from internet. I have also tried by changing instance mame in connection string. But still same error is there. I think I may need to swipe instance name of SQL Server 2005 and 2008. But don't know how to do that.
Any solution please?
According to your error message and this chart you have an MDF file that is version 655 (SqlServer 2008) and you are trying to use it in a machine where is installed Sql Server 2005 that supports till version 612.
Now the bad news. You cannot use that file version in that system. There is no tool that can do a "conversion" of the two files and Sql Server is notoriusly know to not support this scenario
Your options are limited. You can upgrade your destination system to the latest version of Sql Server Express and try to load your file in that renewed system. Usually there is no problem when a newest version of Sql Server tries to read a previous version (not before Sql Server 2005 though). Another possibility is to script your current Sql Server database and then run the script on the destination machine