SQL Server Connection Faulted

Phil capitalized the ‘S’ in server, op did not. “SQL Server”: the Sybase RDMS Microsoft purchased. Specify it as Microsoft SQL Server.

Ethernet/IP is understandable enough. EtherNet/IP (capital ‘N’ there) is/was a marketing ploy by Allen-Bradley. Keenex vs tissue.

I read the post on this forum regularly, thanks all. When I read that question I had no idea which RDMS was involved. I feel a bit dim-witted sometimes. Every reply assumed that it was MS SQL Server. Correctly, I think, but not obvious to me at all.

I had the same issue a few days back. I updated my JDBC driver [From 6.0 to 7.2 I believe (sqljdbc4.jar to mssql-jdbc-7.2.1.jre11.jar)] and that fixed it.

I refereed the manual to perform this driver update. (JDBC Drivers and Translators - Ignition User Manual 8.0 - Ignition Documentation)

Thanks alot, It worked for me in V8.1.7

This also worked perfectly for me on version 7.8
I just took those two items out of the disabled algorithm string.
Had to search elsewhere for the java.security file, but it was easy enough.

image

7 Likes

Just ran into this at our shop when going from 8.1.4 to 8.1.9.

While editing the security.conf file did work, will this get overwritten to default installing the next upgrade?

Likely. It is distributed with the JRE.

1 Like

That’s what I figured. Looks like I’ll have to squeeze in a service pack update for our 2014 installation.

This worked for me too (upgrading from 8.1.2 to 8.1.10 caused all database connections to go faulted)

Just upgraded from V8.1.7 to V8.1.10 and had the same issue and resolved the same way. Is it correct that we will have to do this every time we upgrade from now on unless our IT department upgrade or patch their affected databases SQL Server instances as described here?: Zulu64 JRE and Database Connection Faults - #2 by Kevin.Herron

To quote above:

Yea, was just checking to see if there was perhaps another solution that perhaps IA were working on (eg. while upgrading, checking that file to see if those 2 items had been removed and if so, automatically removing them for the new file. Probably not the best approach to this though I am guessing for reasons that are beyond my understanding. I will see if I can get our IT dep do get this done - hopefully it is not something that they will be too nervous about doing since this is a fairly old but widely used db.

Some might see the annoyance dealing with insecure SQL Servers on each upgrade to be a feature.

5 Likes

This solution worked for me too. I am on version 7.9.5

Thank you! Also, thanks to @pturmel for the lead up to this answer.
I had to connect to an older server that only accepted TLSv1.0 and this was just what I needed to do. This forum and the folks at Inductive Automation rock!

Just upgraded from V8.1.10 to 8.1.12 and everything worked without editing the config file. Could not find anything in the release notes in regards to this…

Thank you, this worked for me as well.
Running SQL Server 2008 10.50.6000.34
Ignition Version: 8.1.9

Crazy stuff.

I have recently upgraded 3 systems
8.1.1 to 8.1.14,
8.1.7 to 8.1.14 and
8.1.13 to 8.1.14

All using SQL server 2019 with the default instance and had no issue.

I just created a new test VM and installed 8.1.14 direct (again SQL 2019 default instance) and got the issue described above.

Thanks to all who contributed as this would have been a real head scratcher.

regards
Dave

To those stumbling upon this thread, Support has released a knowledge base article that covers the workaround for this issue: TLS v1.0 and v1.1 Microsoft SQL Server Database connection issue

3 Likes

One Solution that solved my issue to was to add ";encrypt=false" to the end of my connect URL

example : " jdbc:sqlserver://Hostname\InstanceName;encrypt=false"

1 Like

thanks!