Develop Reference

Connection to remote SQL server breaks when upgrading web server to .net framework 4.6.1

We're currently working on updating our asp.net web application (hosted on IIS 7.5) from .net framework v4.5 to v4.6.1. On small lower environments/local development in which SQL server runs on the same box as IIS, this update works fine and does not break anything. However, once we update our web servers in our test environments which host SQL server remotely from our web servers, our application can no longer establish a connection to the database. We receive this error:
Connection Timeout Expired. The timeout period elapsed while attempting to
consume the pre-login handshake acknowledgement. This could be because the
pre-login handshake failed or the server was unable to respond back in time.
The SQL server is running with CLR version v4.0.30319.
We use Entity Framework version 6.0.0.0 for data access, and the connection strings all use integrated security. Do we need to update the boxes hosting SQL server to .net 4.6.1 also? I don't see why that would be necessary for our app to establish a connection to the database, but I've been unable to find any guidance on MSDN about this.
EDIT:
After this breakage, we downgraded our web servers back to .net v4.5 and we were able to re-establish a connection to SQL server. re-upgrading to v4.6.1 caused the breakage yet again. Therefore, we are relatively sure that the upgrade is the issue, and not a change in application code and/or IIS settings.

Update - so it looks like we've found (at the least the solution to) the problem. Turns out -- as the exception suggested -- that by increasing the connection timeout property on our connection string (default is 15 seconds, we set it to 60 seconds), we were able to make a connection to our database through our web app. However, opening this connection takes a prohibitively long time, so we started looking for solutions to make our connection open faster. We've discovered that we have Netbios over TCP/IP enabled on our database server, and that by opening up UDP ports (137, 138) on our network for Netbios access, we were able to open connections to the database way faster, timing at <1 second instead of >15 seconds.
We're still not sure why the .net upgrade exposed this problem. By testing with a UDL file, we were able to establish that the network connectivity to our database performs about the same on our web servers on .net 4.5 as on our web servers on .net 4.6.1. So it seems as if our connections were opening so slowly that we were already very close to timing out, and some sort of extra logic/cruft in 4.6.1 put us over the edge. I'll update if we find more clarity on that.

The following article describes a new default connection string setting for SQL Server connections in .net 4.6.1.
https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/
This was to solve one problem in some environments, but also caused the issue you are experiencing in other environments.
Basically, you'll want to add the following your connection string:
TransparentNetworkIPResolution=False;

you might want to check the machine.config and web.config files in the windows\micorsoft.net\framework64\v######\config folders. each version of .NET runs on different config files. Since the same code is used in both environments, it must be from the config inherited from here. I am guessing that the 4.6.1 is set to default the connection string to localhost and since the SQL in local and dev are on the same server it is not an issue. You will probably find that the config in the .NET 4.5 version has a connection string defined beyond localhost.
if 4.5 and 4.61 are using the same config files, then make sure you define a default connection string to be used by the entity framework in that web.config.

First of all - this issue appears only when you're using Active Directory authentication.
I've managed dirty-fix: add your MSSQL server to your local (machine which can not connect to MSSQL server) hosts file (%windir%\system32\drivers\etc\hosts).
For example:
192.168.0.5 mssqlserver
It realy doesn't matter the name. It also works well if you have multiple SQL servers on one IP address (connecting through NAT).
This dirty-fix will also fix slow loading using SQL Management Studio issue.

ASP.NET SqlException when publishing in IIS Web Server

I've just start working on an ASP.NET Web Application in Visual Studio 2015 and SQL Server 2014. Somewhere, I need to connect to my local database and I use this:
ConnStr = "Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=my_db;Integrated Security=True";
It works fine when I run the application through VS in my browser. I can access the db and do whatever I want to do. But, when I publish my application in IIS Web Server, and then I open it in browser, it still works OK until I have to access the db. At that moment it throws SqlException:
System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. .
Maybe it is a server name problem and I should use an IP and a Port instead of that name, but I'm not sure because I don't have experience on this.

You are correct: You should use server name and/or IP in your connection string.
Using something like "local" or "localhost" means that your code is not portable. Another option would be to store your connection strings in two separate config files - one for your local copy (for development and troubleshooting) and one for your server (for portability). I have two config files in my solutions:
Web.config
WebServer.config
Then, when I deploy to the server, I just delete Web.config and rename WebServer.config to Web.config. It's totally portable and you'll never have connection string troubles again!
Also noteworthy: you're not including credentials in your connection string, which means that you're using windows authentication when connecting to SQL server. When debugging through visual studio, the application will run as you - and if you have the needed permissions, it will work. However, when running in IIS, it won't be running as you (at least, it SHOULDN'T be) - so you could run into issues there, as well.
EDIT
This link might be useful for you: https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx
Your connection string should look like this:
Data Source=192.168.1.10,1433;Initial Catalog=YourDatabaseName;User ID=SqlUserName;Password=SqlPassword;Connection Timeout=60; Max Pool Size=3000;
(you can set max pool size and connection timeout to whatever you want - or omit them entirely.
Also, regarding your windows issues - you need to make sure that the windows account IIS is using has permissions to traverse your network and reach your SQL Server instance. That said, I suggest that you use a SQL account instead of windows authentication.

Since you are using integrated security in connection string you will have to modify the Identity of App pool under which your application is running.
The Identity will be your windows username and password.
To change the username and password you need to go the advance settings of the app pool and process model you can see identity where you can add your windows credentials
Hope this helps

There are two problems in you connection string:
"Integrated Security" means you are using the native windows system for authentication. Similar to opening SSMS on the database using your Windows password. IIS is now trying to connect to the database, and connection string is telling to use the process that IIS is running under.
You can create a non-windows user in SQL Server and put the credentials into the connection string. Or you can grant the IIS user DB privileges. Or you can a lot different things here, but theses are the easiest to get you moving.
THe second problem in the connection string is the data source. Is there SQL Server on you local machine? If so that's why it's not working. Try to run your app in VS but against the remote SQL Server. That should be your next step.

The problem was that I thought that SQL Server was installed automatically with VS or at least with SQL Server Management Studio. BUT NO. So, as far as I understand, till know I have not worked with a real SQL Server. When I checked SQL Server Configuration Manager there were nothing running at SQL Server Services and so I realized that I was missing something.
Then, I installed SQL Server Express and build my db there. Now it is working fine even when I publish it. The connection string is
Data Source=.\\SQLEXPRESS;Initial Catalog=my_db;User ID=username;Password=pass
It can also be:
Data Source=localhost\\SQLEXPRESS;Initial Catalog=my_db;User ID=username;Password=pass

Web App to SQL Server Not Connecting ( Error Locating Server/Instance Specified)

I know this is an often asked question, but I'm still receiving this error and I have tried:
Using localhost, the IP address and the instance name in the
connection string
Changing the SQL Server Configuration Manager so
Named Pipes and TCP are both enabled Ensured the database is set to
allow remote connections
Opened 1433 & 1434 for UDP & TCP in Windows Firewall, in fact I
tried turning off the firewall for a moment to see if it would
connect
Ensured the browser & the MSSQLSERVER service are both up and
running using NETWORK SERVICE
Now for some oddness. The SQL Server instance and the IIS running the website are on the same machine.
If I open a browser and browse to the website I get the error. If I open a browser on my local machine and browse to the website I get the error. If I change the connection string in my development PC to the IP address of the remote server running SQL server and debug the application it connects and runs without error!
I am totally at a loss now as to what could be the error.
This is SQL Server 2008 RC2.
I'm on the verge of giving up - I very much appreciate the efforts you guys have made, I have tried all the suggestions here and I am coming to the conclusion that something must have gone awry in the set-up of the server, the website or the database. Just to reiterate if you remote desktop onto the server and connect to the website using http://gdservers you can login and it all works fine, if you use http://gdservers.<domain>.co.uk the login fails. The error in the event log is a membership credentials failure, not blocked by firewall or anything like that. If there's any other suggestions I'd love to hear them, thanks again.

If your web app intends to use SQL Server Authentication with a SQL login/password then make sure that your connection string explicitly states Integrated Security=False. Otherwise your connection may default to Windows Authentication and not behave as expected.
Edit
Also, be sure that the connection string you're tweaking is the one that is actually being used to make the connection. Sometimes things can get confusing when an application has multiple components that may have their own configuration settings. For example, the problem in the thread here turned out to be:
I was updating the connection string on the web.config but, it's a multitier application, the data access component is in a separate .dll and has its own connection string.
Edit
I'm beginning to wonder if the SQL Membership Provider is using Windows Authentication to connect to the SQL Server even if your data connections aren't. Check out the video here and perhaps review your settings (especially the authentication setting in the provider setup steps).

I don't think anyone spotted it and I only spotted it on Wednesday and then realised I'd made another error. If someone has mentioned it above let me know and I'll change the award and give them the points.
The applicationName was missing from the membership provider. I spotted it on Wednesday and added one in, what I didn't realise I'd done is made a spelling mistake when adding the applicationName in, so when I did this, it didn't fix it, so I thought it wasn't the problem.
Yesterday whilst reviewing the code I noticed I spelt the applicationName 'GSServers' instead of 'GDServers' when I changed it, it all started working.
Not a very satisfactory conclusion and I apologise.
Thank you to everyone who tried to solve this problem and sticking with it.
As I said if someone did mention this in an answer or comment somewhere let me know and they can have the points.

Stupid question but, have you checked the credentials of the login? I'm still very much a noob in this area but I found out thru backing up and restoring a database (at least in MS SQL Server) that the restored user login doesn't work.
I've had to delete the user from the database and add it back in, then everything works fine. Could it be you are accessing a different version of the database on the non-working machine?

How are you indicating the Data Source/server name in your connection string? I've encountered situations where there was a hosts file on the server redirecting elsewhere, or the server was indicated by a domain name which resolved to the external IP address of the server, or other similar oddness.
Also, if you have SQL Serve installed on the server, do you also have Management Studio installed there? It's the quickest way to rule out code or permission errors, just trying variations through Management Studio until you find login details that work (or know that none do).

Usually the easiest and most secure way is using integrated security:
<connectionStrings>
<add name="HitCounterContext"
connectionString="Data Source=(local)\SQLEXPRESS;Initial Catalog=db;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>
Make sure you use the correct instance name, which per default is "SQLExpress". I don't know how IDEs work with that, but using this connection string with IIS should at least connect successfully (which is not equal to authentication).
Maybe the authentication fails because your database must have a user for the app pool account. If you disable custom errors in your web.config so you get .net error messages, the error message should tell you that the authentication failed for the app pool user (the message actually tells you which user is used). For instance: If you create a new website called "yoursite.com" using IIS 7, per default it creates a new app pool with the name "yoursite.com". With that you'll have to add a user to the database for IIS APPPOOL/yoursite.com (might not be in the users list) and let it be the db_owner for testing.
Add the user for the app pool using "SQL Server Management Studio" like that (sorry it's german. This actually is the form after the user was added, but it should look the same while adding):
After that, your users list should look like
and the servers login list like
where each app pool has its own login for the server and user for the respective database.
By the way: Connecting from the Management Studio works just the same like from your asp.net app, except that you normally use your current user with SMS:
So, if this works, the connection from your app should do as well. The rest relies on the user for the app pool.

The fact that it's trying to login as sa locally suggests you're not using the connection string in your code; I don't think it's a SQL server problem, but an app problem.
In your app, make sure you're actually using the value of the connection string. Don't use the default constructor. E.g.
using(SqlConnection conn = new SqlConnection(WebConfigurationManager.ConnectionStrings["myconnectionstring"].ConnectionString)){ /* .. code */ }
not
using(SqlConnection conn = new SqlConnection()){ /* .. code .. */ }
If I change the connection string in my development PC to the IP address of the remote server running SQL server and debug the application it connects and runs without error!
It's possible you're dev box has been added an authenticated login, and it's automagically "working".

Comment: Using SSPI with a windows user account is preferable from a security perspective.
Answer:
Port 1433 is used for SSL by the default (unnamed) instance.
Ensure that your named instance has an SSL port properly assigned:
http://blogs.msdn.com/b/sqlexpress/archive/2005/05/05/415084.aspx
Try these connect strings (note that they don't use 'localhost' - which is case sensitive, I believe):
'Provider=SQLOLEDB;Data Source=COMPUTERNAME\SQLEXPRESS;Initial Catalog=Test;User ID=COMPUTERNAME\USERNAME; Password=PASSWORD;Integrated Security=False'
'Provider=SQLOLEDB;Data Source=.\SQLEXPRESS;Initial Catalog=Test;User ID=COMPUTERNAME\USERNAME; Password=PASSWORD;Integrated Security=False'
'Provider=SQLOLEDB;Data Source=.\SQLEXPRESS;Initial Catalog=Test;User ID=COMPUTERNAME\USERNAME; Password=PASSWORD;Integrated Security=SSPI'
ADDITIONAL EDIT:
Whenever client is run on same machine as SQL Server, the error occurs. When client is run from dev machine, no error. You may be failing to resolve the machine name because DNS does not support any of the names.
Suggestion: Connect using localhost. Ensure you can ping localhost and/or telnet localhost 1433. Ensure your hosts file (e.g. C:\Windows\System32\drivers\etc\hosts) has entry:
127.0.0.1 localhost
Alternatively, use: (local)\INSTANCENAME
Run SQLCMD –L to list installations (confirming correct browser operation).
Ensure you don't have older versions of the management tools ensured on the same server. E.g. 2008 & 2005 tools cannot coexist - but 2008 tools are backwards compatible, so you can delete both and just cleanly install 2008.

Publishing Silverlight application that uses WCF to connect to database

I have a silverlight application that works perfectly on my local machine but, when i try to run it from a web server it does not work.
I've been researching a lot and i ended up installing the fiddler web debugger tool which gave me a little better idea of why my application was failing. I think the way i'm connecting to the database is whats causing my issue. This is what i'm using:
string myConnectionString = "Persist Security Info=False;Integrated Security=SSPI;database=Database;server=Server;Connection Timeout = 600";
After a little bit of research i learned that Integrated Security = SSPI means that the current machines credentials will be used to connect to the database which is why the program works on my computer and not the webserver.
I don't know if i'm thinking about this correctly, but i'm pretty sure this is my problem. The error that Fidder reports is: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGIN'.
I also read that I should specify userId and password in the connection string, but i don't know what values to use for these fields (when i connect to sql server 2008 i use Windows Authentication option and i only supply a user name.)
I can post any code that may help to clarify my situation.
Edit: if it helps at all, i am able to visit DatabaseService.svc in the browser without any errors.
What do i have to do to overcome this issue?

Can't connect to SQL Server database

I'm currently developing a web application using asp.net c#. I got a server where I today was
going to publish my website and its database. Its a server that runs Windows Server 2008 R2.
But I have one issue:
My website doesn't seem to get access to the database. If I run the website from another computer on my local network I can access the server's database, BUT I can't when I run the website from the same server where the database is. This is really weird. I hope someone can help.
I just get an error that says, it can't access the database.
The most weird of all is that I'm using the same connection string on both computers, but it still doesn't work. Are there maybe some sort of settings in Windows Server 2008?
Here is my connection string:
<add name="ConnectionString"
connectionString="Data Source=AXELS;Initial Catalog=Sailor;Persist Security Info=True;User ID=sa;Password=saab123"
providerName="System.Data.SqlClient" />

Since the connection works on one machine and not on another, I'd guess you have an issue with a firewall or similar - but it will be hard to tell until we see the actual error message. Until then, there are a few things you might want to do:
If it appears as if the connection has to time out before you get the error, it indicates a connectivity problem. Do you have a firewall between the two servers? Does the database server have a firewall that explicitly lets your machine (or internal) machines get through, but hasn't been setup to let the webserver get through? You have to make sure that port 1433 is open on the server.
Are there other sites on the webserver that can connect to the database?
If you have console access to the server, try to set up an ODBC from the server to the database - usually in Control Panel -> Data Sources (ODBC). If you set up a connection with the same DB Server, username and password and test the connection, you might get some pointers to what is wrong.
If the above doesn't provide you with an answer, I'd try to go through the steps described here:
http://blog.sqlauthority.com/2009/05/21/sql-server-fix-error-provider-named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server-microsoft-sql-server-error/
And if that fails, take a look at this - which is apparently only valid when you get SQL Network Interfaces, error: 26
http://blogs.msdn.com/b/sql_protocols/archive/2007/05/13/sql-network-interfaces-error-26-error-locating-server-instance-specified.aspx

This is probably a permission problem.
You need to show us your connection string so we can see how exactly you try to connect to your database.
For example, if you are using Windows authentication, maybe your app runs under different accounts on both machines - and the account on the other computers has permission to access the database, but the account on the database server has not.

Have you checked the if the protocols you are using are enabled on the SQL Server e.g.
C:\Windows\System32\cliconfg.exe -- 64 bit version
C:\Windows\SysWOW64\cliconfg.exe -- 32 bit version
or check SQL Server Configuration Manager 'SQL Server Native Client *' tabs.

This is only applicable if you do not use Windows Authentication, else read the post about priviliges from Christian Specht - in this case I agree.
The fact that you can connect from another PC on the network means that all you database settings, user accounts and permissions are probably set up correct.
It seems there might be a issue with the way the server resolves localhost, as it will try to resolve the Data Source to localhost because AXELS = localhost on that machine.
Have a look at your hosts file and see if there's any funny pointers except for the default.
Located in C:\Windows\System32\drivers\etc
There should be an entry: 127.0.0.1 localhost