Existing connection forcibly closed by remote host

[bazzer747 25]

I run many Windows applications connecting to MSSQL Servers via Firedac, and have done for many years. My 'Live' connectivity to the tables and views work OK, but in the last 2 weeks my connectivity to a 'test' Server is throwing up the error shown in the attached screenshot "An existing connection was forcibly closed by the remote host." 

In reporting this to the hosting company they are saying the 'test' Server should have no issues connecting to it, and I'm saying why, then, can I connect all my applications to the 'Live' Server with no problems, but none of these applications now connect to the 'Test' Server (when they did connect a couple of weeks ago?) 

 

They have come back with suggestions that seem to indicate using TLS1.2 may solve the issue.

 

It seems TLS1.2 and TLS1.3 are enabled by default in Windows 11 (my local PC is Windows 11 Professional), but I'm finding it difficult to verify that. And I'm thinking this is a red herring anyway.

 

My question her6e, really, is has Firedac any involvement in what version of TLS is used &/or is this something Firedac has an answer to that error?

[bazzer747 25]

I have ODBC Driver 11 for SQL Server and ODBC Driver 17 for SQL Server on my local PC. As this message seems to relate to the 11 version, does that mean Firedac somewhere is told to use the 11 version rather than the 17 version? 

 

Could I remove the 11 version and Firedac would automatically revert to using the 17 version?

[Lajos Juhász 295]

Unfortunately docwiki is down. I cannot comment on how you can configure SQL Server as I am not using that database. About the driver that is loaded you could try to query the FDConnection using the method GetInfoReport:

 

https://docwiki.embarcadero.com/Libraries/Sydney/en/FireDAC.Comp.Client.TFDCustomConnection.GetInfoReport

 

Google returned this https://stackoverflow.com/questions/64048094/connect-firedac-to-sql-server-through-odbc-driver-17-instead-of-sql-server-nativ:

 

1

For design time: drop a TFDPhysMSSQLDriverLink on the data module or form and set the ODBC driver to: ODBC Driver 17 for SQL Server in the drop down.

After that open your TFDConnection and switch to the Info tab and check what driver it ends up using along with any notes it mentions.

Note from the OP: To work for me I've needed to give a name to the TFDPhysMSSQLDriverLink component on its DriverID property, and set that name to the DriverName property of the TFDConnection.

Edited June 25 by Lajos Juhász
edit stackoverflow answer.

[bazzer747 25]

That's cracked it. I changed the driver to v17 (from 11) and it connects with no issues. I think the hosting company has uprated the server I couldn't connect to so it didn't allow driver v11 to connect, whilst the other two servers I had no trouble with still allowed v11 to connect OK.

 

Many thanks for your help, I can now continue with my development/text work!

[Davidmenk3 0]

On 6/26/2024 at 6:27 PM, bazzer747 said:

That's cracked it. I changed the driver to v17 (from 11) and it connects with no issues. I think the hosting company has uprated the server I couldn't connect to so it didn't allow driver v11 to connect, whilst the other two servers I had no trouble with still allowed v11 to connect OK.

  

Many thanks for your help, I can now continue with my development/text work!

Great to hear that changing the driver to v17 resolved the connection issue! It sounds like the hosting company upgraded the server, causing v11 to fail. For anyone needing reliable hosting services, you can buy VPS online from HostNoc to ensure seamless connectivity. Thanks for your help, and good luck with your development work!

Edited August 1 by Davidmenk3