Last post Feb 05, 2016 07:58 AM by Candice Zhou
Jan 29, 2016 03:18 PM|Stewa11|LINK
Create a new project, add new item, data, Link to SQL, create a dbml DataContext, drag and drop your tables for your DEV server.
Lots of coding...Testing... ready to deploy to the next server.
Deploy code and database to a different server.
Is it enough to change the DataContext's connection string? What is best practice?
The reason why I ask is because the original server is referenced in the dbml autogenerated code. The service runs fine between servers with a simple connection string change. I assume the app.config connection string over-rides the autogenerated reference.
Feb 01, 2016 08:00 AM|Candice Zhou|LINK
Find the <connectionStrings> element, add the following connection string to the <connectionStrings> element in the Web.config file:
connectionString="metadata=res://*/ ContextClass.csdl|res://*/ ContextClass.ssdl|res://*/ContextClass.msl;provider=System.Data.SqlClient;provider connection string="Data
Source=ServerName;Integrated Security=False;User Id=userid;Password=password;MultipleActiveResultSets=True"" />
Then, modify the name of the connection string that match the name of the DbContext class.
Feb 02, 2016 09:57 AM|Stewa11|LINK
Many thanks for your replay Candice I very much appreciate it.
The contextclass connection string is changed when the coce is migrated from server1 to server2.
The auto-generated code for the datacontext still has a reference to server2.
Am I safe in assuming that the webconfig connection string over-rides the autogenerated reference?
the .dbml code contains: ConnectionString="Data
Source=server1;Initial Catalog=database;Integrated Security=True"
Feb 05, 2016 07:58 AM|Candice Zhou|LINK
You could refer to this tutorial about Migrating Server: