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.



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.