I have a complex problem and I am not sure what is causing it. The short of it is, I pretty much have access to test anything I need to, but I am not sure the best way to troubleshoot a database connection string issue in my scenario.
My development environment is quite a bit different than my test environment. My test environment is in a DMZ. My development environment is within the same domain as the database server.
In my development environment, I am running on my desktop and connecting with a connection string and using a trusted connection.
Int the DMZ I have deployed my files on a system drive that IIS 7 points to on the same server. Because the test environment is on the DMZ, I am using an ip address of the server and a special port number that I must specify in my connection string.
My web application does not house connection string. I keep connection string in a .cs file and based on Evironment.machineName variable in .Net, the application decides at runtime which connection string to use and stores that into a global static varibale so I basically have:
public static readonly string strDBConnDev = "connection stuff here";
public static readonly String strDBConnTest = "connection stuff here";
public static String strDBConn;
Then I have a function that fires on a pageload that runs
public static void setEnvVars()
{
// This is psuedocode
if(environment.machinename = "mydevmachine")
{
strDBConn = strDBConnDev;
}
if(environment.machinename = "mytestmachine")
{
strDBConn = strDBConnTest;
}
}
I make a connection on dev that is successful. The connection string, or something about it is not right. I am using the .Net Data Provider, using
System.Data.SqlClient. It is important that I continue to use this. I have not configured any connection string in the IIS 7 database section as that has not seemed to be necessary in our other environments.
According to an article I found: There are 2 formats. The one that my dev machine uses
// .NET DataProvider — Trusted Connection
using System.Data.SqlClient;
SqlConnection conn = new SqlConnection();
conn.ConnectionString =
"Data Source=ServerName;" +
"Initial Catalog=DataBaseName;" +
"Integrated Security=SSPI;";
conn.Open();
and the connection via ip that i need my test in the dmz to use:
// .NET DataProvider — via IP Address
using System.Data.SqlClient;
SqlConnection conn = new SqlConnection();
conn.ConnectionString =
"Network Library=DBMSSOCN;" +
"Data Source=xxx.xxx.xxx.xxx,[port number];" +
"Initial Catalog=DataBaseName;" +
"User Id=UserName;" +
"Password=Secret;";
conn.Open();
My conundrum is that I have troubleshot to the point that I know that that connection string variable is being set when in the DMZ. However my connection fails and yet I do not get an error. It just fails quietly. I checked IIS logs on the DMZ and found no evidence of a clue or hint. I also checked the windows Application logs and did not find anything there, which I thought was pretty surprising.
I feel stuck at this point because I feel like I need troubleshooting ideas so that I can understand and test the connection and visibility and credentials of the database server from my dmz host.
A little background in how I am deploying is that I am building on my machine, then copying the files to my c# web application to the folder on the dmz host. The code runs nice until it tries to make a call to the db.
I feel like I need some help with my “skills”, basically knowing when / how to troubleshoot and also what to ask of my network peeps.
This problem had no response but the issue was solved. I troubleshot the connection by the following:
1) Check accessibility from the dmz web host to the internal database server
confirmed that it was reachable.
2) Determine why connection string in my .net application was not working
I couldn’t troubleshoot the message, so a co-worker suggested running
LinqPad on the dmz host >>
Problem…I had created a database account (because you can’t use a trusted connection or Windows pass through authentication from dmz to internal db host) and I had not given the account any select access to the database.
Problem solved by making sure my database account was set up the right way. It was the first time that I had heard of Linqpad, but it ended up being a really cool troubleshooting tool because you can run some .net scripts without having to even start a project or compile, so it saved some time.