Why Does Only One Of These Connection Strings Work When They Are Actually Identical?

I have 2 identical connection strings. One is for ASP.NET membership etc and the other is for everything else. I can log in to my application, so the following connection string ob

Solution 1:

This connection string is actually pass the control to the system

Data Source=SBS;Initial Catalog=CustomerIntranet;Integrated Security=True;

By saying control, I mean that the system, together with the database check if he allow or not to connect to the database. So that is the reason that works on one case and not on the other.

What I suggest, first use localhost on Data Source=localhost, except if you connect to a different computer, then make sure that the name of the computer is properly configured on host file of your server, or just use direct the IP.

Second open the database management and make sure that the catalog exist, and your pool that try to connect have permission to read that catalog. Also the file of the database must have permissions for the pool.

The pool is running under a user account, or a system account. That account must have permissions to read/write that database, both on the files of the database, and on the preference of the database. Also that user must be on the grand list on the database.

Solution 2:

I found out what the issue was to this problem. Let me first add some more information relevant to the issue.

I am using an n-tier architecture with a typical DataAccess, DataClasses (Typed datasets, xsd file), Business and Presentation layers.

A solution wide search for connectionString reveals multiple hard coded connection strings (Courtesy of VS) that were not being overridden by the web.config. These are obviously created during the set up of the DataSet designer.

When deploying the application, the web.config connectionStrings reflect the production server but the hard coded strings still refer to my development server.

My limited understanding is that the web.config is supposed to override any other connection strings defined elsewhere in the application if they have the same name. It seems as this is not the case. Somebody wiser than me might be able to elaborate on that.

In short, if you are having any bizare issue like I did, do a solution wide search for any other connection strings. They might exist without your knowledge and they may be causing a conflict.