Notes : ConnectionString Checks ...

1. When you pull in the DB tables into a dbml file, the ConnectionString property under the Properties window of the dbml file gets set to/points to the DB whose tables you pulled into the dbml file.

2. So, what we need to do is always clear the ConnectionString property and set it to None.

3. The reason we need to always make sure that the ConnectionString property in the property pages of the .dbml file is set to None is as follows :

let us say, we created the dbml file off of Dev/Test DB tables, the connectionString will automatically get updated to point to DEV/Test. Now you keep working on your changes/updates in the code and when it is time to promote to live, all that you do is change the Web.Config file to point to Live DB (you have forgotten in the long process of making changes that you had created your dbml from a DEV/Test DB). But the ConnectionString of the dbml file is still pointing to DEV/TEST...This can lead to a lot of problems, which will show up in the form of data not showing appropriately/suitably for the front-end users, because what they are entering may be partly going into Live, partly into DEV, who knows where ..

To AVOID these issues always make sure you follow these steps to ensure that your dataSource is what it needs to be, both at the time of Testing and Promoting to LIVE :

Say you are promoting to LIVE :

a. Your dbml file should contain tables from the LIVE DB.
b. The ConnectionString property in the Property pages of the dbml file should be set to NONE.
c. Everywhere where it needs to be, the Web.Config should have the ConnectionString set to the LIVE DB.
d. Inside the source code you should be explicitly passing the DSN to any calls to the DataContext Class objects, defined in the dbml designer file. DataContext classes contain definitions of all the tables and fields inside the database.
In other words, do not use any parameterless DataContext class constructors -- pass to them the specific ConnectionString variable that you want your source code to point to.
e. before promoting, put a Breakpoint on one of the constructors of a DataContext class and check the value of the DSN/ConnectionString in the Watch window to make sure it is pointing to the right Database.

When DEPLOYING REPORTS (REPORTING SERVICES REPORTS TO THE REPORTS SERVER)

1. If there are going to be several reports based on the data in one common database, create a SHARED DATASOURCE. Make sure it points to the correct datasource. You may want to deploy this Shared dataSource to the report server.

2. Make sure that each report is pointing to this shared datasource or if each report has its own datasource, make sure it is pointing to the correct datasource (Test/DEV/Live) before deploying to the Report server.

3. Also, always go under Project Properties to make sure that you are pointing to the correct Report Server URL/address so when you deploy your reports, they get deployed on the correct Report server.