Unable to connect to SQL Server using SqlConnection (but OK with OleDbConnection) - sql-server-2008

I have a SQL Server 2008 instance running on Amazon RDS and another test database server running as a SQL 2008 Express installation on an Amazon EC2 instance.
I am able to connect to both of these servers using SQL Server Management Studio (and other tools like Navicat) so, I am happy that the servers are correctly configured to accept remote TCP connections and that there are no firewall issues.
However, when I try to establish a connection from a C# application, using SqlConnection, it fails with a timeout. But, if I try the same experiment using an OleDbConnection it works fine (after adjusting the connection string to include the provider information).
For comparison, if I run the experiment on the EC2 instance, using an SqlConnection with a connection string that establishes a (local) connection, it also works correctly, so I assume the issue is related to the use of SqlConnection remotely.
Does anyone have any idea what I need to do to get SqlConnection working, or what steps I could take to further diagnose the cause of the problem?
Many thanks for your advice,
Tim

Apparently this behavior is caused by this issue and, in my case, it was specifically because my PCTools firewall was doing something unexpected with the outbound TCP packets created by SqlConnection.
I implemented a temporary workaround by uninstalling PCTools (it was not sufficient to merely disable the firewall), so I now have to find a new firewall that complies with what Windows/SQL Client is expecting.

Related

Pomelo MySQL (.NET Core) Can't Recover After Database Failure

Last night AWS RDS had an "Internet Connectivity Issue" that was resolved a short time later. However, my app (which runs in .NET Core and connects to an RDS MySQL instance via Pomelo.EntityFrameworkCore.MySql) could never re-establish a connection to the database even though the MySQL server was back online. I tested connecting from my own local machine and it worked just fine. I then re-deployed the .NET Core app it everything started working again.
Is there something that I need to re-create (the db context perhaps), or is there something that is being cached that I need to flush to try to connect again? I connect via hostname, and my connection string looks something like this:
server=something.somewhere.us-east-2.rds.amazonaws.com;userid=XXXX;password=YYYYY;database=ZZZZ
Here is the Exception being thrown:
MySqlException: Unable to connect to any of the specified MySQL hosts.
at MySqlConnector.Core.ServerSession+<ConnectAsync>d__56.MoveNext (C:\projects\mysqlconnector\src\MySqlConnector\Core\ServerSession.cs:239)
and here is how I create my db context in Startup.cs:
services.AddDbContext<BlayFapContext>(opt => opt.UseMySql(Settings.Instance.SQLConnectionString));
Any help would be greatly appreciated.
Giawa
Okay, we worked out what happened. Pomelo's MySQL wrapper had an issue as outlined in their git repo here: https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql/issues/434
Basically, if a MySQL database is not available when the connection string is first used then it will be cached as invalid and will never work again. You can easily confirm this by launching a service with no MySQL connectivity, verify it doesn't work, then launch MySQL and confirm that the service still doesn't work. It can never establish a MySQL connection after the first connection string is found to be invalid.
They patched it shortly after the 2.0.1 release, but they haven't updated Nuget with a new version since then, despite the issue being found 6 months ago. So, the fix is to checkout their repository source code, and patch it ourselves. We found the fix here works just fine: https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql/pull/456
So, why was the connection string retried? We already had a successful connection! It turns out that the internet connectivity issue with the Ohio data center was not limited to RDS, but also affected EC2. Our EC2 instance was rebooted as part of the fix, and the MySQL connection wasn't valid when it reboot due to the continued connectivity issues. The state of that connection was cached, and even though the MySQL server came back online our service was toast.
Giawa

Unable to connect to any of the specified MySQL hosts in NHibernate, MySql

One of the client is reporting this issue happening in our application. NHibernate throws Unable to connect to any of the specified MySQL hosts in the middle of the app running, so it is not a mistake in the configuration. It happens randomly, but always when the transaction is opened.
I saw this:
NHibernate, MySQL, Windows Server 2003 -- connection problems
But the server in my case is Windows 2008. And app opens only single connection simultaneously. MySQL version is 5.5.28. Server is on the remove machine
Unfortunately the app requires the HW I do not have, and I cannot reproduce it locally.
Any ideas or directions I need to dig in?
Try connecting using the full directory name, e.g. instead of Server=SRV use
Server=SRV.yournetwork.com
It might be that is has trouble resolving the server name.

Connection String for Remote Connections to SQL Server 2008

I am trying to connect remotely to SQL Server 2008 R2 Express on a server running Windows Server 2008 R2. I receive the following error:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: TCP
Provider, error: 0 - A connection attempt failed because the connected
party did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.)
I think the problem might be related to my connection string, because I am not sure exactly what it should be. I understand the connection string should take the form:
Data Source=123.123.123.123\InstanceName;Initial Catalog=MyDBName;user id=MyUserName;password=MyPassword;
The instance name of my SQL Server installation takes the form ComputerName\SQLEXPRESS. This is what I see when I log in to Management Studio on the server. So should the connection string begin with
Data Source=123.123.123.123\ComputerName\SQLEXPRESS
This looks wrong because of all the slashes. I have tried to omit the computer name thus:
Data Source=123.123.123.123\SQLEXPRESS
I also read somewhere that you can specify a port so I have also tried
Data Source=123.123.123.123,1433\SQLEXPRESS
because I understand that 1433 is the TCP port used by SQL Server and
Data Source=123.123.123.123,1434\SQLEXPRESS
because I understand that 1434 is the UDP port used by SQL Server browser.
I have also tried every combination of these and they all give the same error.
These are the steps I have taken to enable remote browsing on the server:
In Management Studio, right click the instance, go to Properties, Security and check SQL Server and Windows Authentication Mode. On the connections tab I have checked "Allow remote connections to this computer".
In SQL Server Configuration Manager I have enabled all four connection options (Shared Memory, Named Pipes, TCPIP and Via) under every node they occur. Under protocols for SQL Express I have tried specifying port 1433 and also leaving it blank with TCP Dynamic Ports set to 0 (which I think is meant to enable dynamic ports).
I have created firewall exceptions for TCP Port 1433, UDP Port 1434, and program exceptions for sqlservr.exe and sqlbrowser.exe.
If someone could tell me which of the four versions of the DataSource part of the connection string I should be using it would be a great help, even if it did not solve the problem. It would mean that everything I try subsequently I would only have to test once instead of four times.
Thanks in advance for any help!
Where did you enter the firewall exceptions, on your machine, on the server, or both?
The second connection string is the only really valid one. Can you telnet to the server on port 1433? Can you connect to the instance from Management Studio remotely and the problem is only from your code where the connection string is? Did you try running the same code on the server? Did you try forcing TCP/IP (vs. named pipes/shared memory etc) adding the following parameter to your connection string:
Network=DBMSSOCN;
This question comes up quite a lot and I'm sure you're hitting something that others have hit before. Have you gone through this article, "How to troubleshoot connecting to the SQL Server Database Engine"? Also there are 20+ questions on here that mention this error message and Express, according to this search result. I suggest double-checking your settings against some of the items in those answers that solved the issue for other users.

A transport-level error has occurred... (Existing connection closed by the server) Sql Server 2008

I have a web application which is currently running on Windows XP operating system with SQL Server 2005 database and IIS 6.0.
Now, we are trying to upgrade it to IIS 7.0 on Windows Server 2008 and SQL server 2008 database.
When I run the application then it is throwing "A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)" randomly at different database calls.
I have verified using "sp_who" that only one connection which I am using is opened.
Can anyone tell me, what could be the cause of this issue?
This blog post by Michael Aspengren explains the error message "A transport-level error has occurred when sending the request to the server."
Maybe the database is set to auto-close? This used to be the default for databases created on the older MSDE/Express edition.
ALTER DATABASE YourDatabaseName SET AUTO_CLOSE OFF;
More:
The SQL Server 2005 Express Edition Overview states:
Features like Auto-Close and the ability to copy databases as files are enabled by default in SQL Server Express ...
I can't remember which service pack changed the default, but the New Database UI in the SP3 version of Management Studio Express defaults the Auto Close setting to false.
This is an error that occurrs when connecting to database due to a lower layer network-related error that you cannot handle from Sql Server.
It would be great that the API used to conenct handled this error but AFAIK it is not. The only way to solve this is to retry connecting to the database when this error occurrs.
You should try to reconnect at least a couple of times more to get sure that the error is not persistent and if it is the case then throw the exception. My experience tells me that trying to reconnect, the 99.9% of times you will succed.
Often, it's the database being offline/closed or the SQL Instance being restarted/offline
In my case. We have DELL R720, NICs are on board and PCI Broadcom NetXtreme Gigabit Ethernet cards. We run into two issues.
Network speed is very slow for HyperV VMs. The solution is to disable the "Virtual Machine queues" of the HyperV host Broadcom nic property windows. It is in the Advanced tab.
SQL client having this transport level issue. It only happened once in every 10-15 min. At the same time the RDP service kick out client from time to time also. The solution is to disable the "Large Send Offload V2" of the HyperV host Broadcom nic property windows. It is in the Advanced tab.
Check if you have MultipleActiveResultSets=true; set in your connection string.
Transport level errors are often linked to the connection to sql server being broken ... usually network.
Timeout Expired is usually thrown when a sql query takes too long to run. Is this the scenario in your case? Like stored proc taking too much time to execute or are there are batch jobs that are executed?
Use clearpool(urSQLconnection), along with dispose. This will clear the dirty connection. and you can open new connection.
Got this trying to execute commands from multiple threads on one connection object in .net, that was a stupid mistake. Locking it or using a separate connection per thread fixes that.
In my case it was McAffee that was pre-installed. Can tell if it was conflict with other solutions or not. The connection was on VPN, on WiFI. Maybe this will help someone in future.

How can I connect to Sql Server 2008 remotely using an IP Address?

When I publish my project clients will need to be able to setup the initial configuration, and part of that is the Sql Database Connection. I have an instance of Sql Server 2008 running on my system (MSSQLSERVER2008) as well as SQLEXPRESS2005. I am trying to use the following connection string locally just to see if this works, and I can't get it to work:
ConnectionString = {Data Source=127.0.0.1;Initial Catalog=DCOMProductionsDesktop;Integrated Security=False;User ID=DCOMProductionsDesktopService;Password=;Network Library=dbmssocn}
The error I get is the usual "The target machine actively refused the connection".
*There isn't any firewalls running, and its inside the network anyway
*TCP/IP Protocols are enabled
*Remote Connections are enabled and permitted
So, I'm stumped.
Edit
I changed the connection string's data source to:
DataSource=192.168.0.2\MSSQLSERVER2008 on my WinXP VM (for testing remotely)
Now, this did work. But when I deploy this across the internet, will that same connection string work for clients outside my network using a domain name such as:
DataSource=desktop.dcomproductions.com\MSSQLSERVER2008
Or will I need to do something different?
It will work, as long as "desktop.dcomproductions.com" or whatever, resolves to the proper IP address. So that name should be set up either on the public or private DNS properly.
Also, make sure it resolves to a public/external IP address, unless your client's scripts are going to be within the same network as the SQL server.
Thought I post it as an answer, instead of comments :)
It's been a while sice I used anything but Named Pipes to connect to a sql server instance so this may not be relevent but try changong Data Source to Server.
They may be synonyms, as I said, it's been a while.
Also, even if you are using an IP address, you aren't specificying an instance of sql server to connect to, that may also be causing issues