Why is the Ignition Alarm Journal faulted on one Vision client?

One Vision client fails to load its Alarm Journal table and logs Error fetching alarms. It is the client running on the PC that also hosts the MySQL alarm database. The second client and the Designer read the same journal normally. The stack trace settles where the failure happens. A gateway raises the exception, not the client, when that gateway asks its Historique_Alarmes connection pool for a MySQL session and finds the connection FAULTED.

The client's physical position next to the database does not matter. What matters is which gateway services the client's requests, and how that gateway reaches MySQL. With redundant gateways, there are two independent answers to that second question.

Where along the path does the journal query stop?

A Vision client never opens a JDBC connection to MySQL. The Alarm Journal Table sends a request to its gateway. The gateway runs the query against its own connection pool and returns rows or an exception. Read the trace from the bottom Caused by upward and you get the hops in order:

The GatewayResponse$GatewayThrowable wrapper means the exception was created on the gateway and serialized back to the client. The client only displays it, under logger Vision.Components.AlarmJournalTable at WARN severity.

A client-side network problem produces a different symptom: a gateway communication timeout or lost-connection banner. It does not produce a named datasource fault. So the failing hop is gateway-to-MySQL, on whichever gateway handled this request.

Which gateway is this Vision client actually connected to?

This is the first check, and it explains most one-client-only failures. A gateway whose Status page shows the connection as healthy cannot have produced this exception at that moment. Either the client is talking to a different gateway, or the pool state changed between readings.

Take these readings:

1. On the failing client, open the Client Diagnostics window. Note the gateway address the client is connected to.
2. Check the launcher or shortcut on that PC for the gateway address it was configured with. Also check any failover or alternate address.
3. On both the master and the backup gateway web pages, open the Status section and list the connected Vision clients. Find which gateway lists this PC's session.
4. Record the redundancy state of each gateway: which one is active, and which is in standby.

With redundancy, the database connection configuration replicates from master to backup. Each gateway still builds its own JDBC pool from its own host. That means each has its own name resolution, its own network route, and its own match against MySQL's user-and-host account table. A green connection on the master tells you nothing about the backup's pool, and the reverse is also true.

What does the Historique_Alarmes status read on the serving gateway?

The exception text says See Gateway Status for details. Open the database connections view under Status on the gateway identified in the first check. Find Historique_Alarmes. Then open that gateway's logs. Filter for the connection name around the client's error timestamp (3:56:04 p.m. in the captured fault).

The MySQL driver's exception text in the gateway log classifies the fault. Typical messages are a communications link failure, access denied for a user at a host, too many connections, or an unknown host. Carry that text into the next check. Rebooting the PC did not clear the fault, so the cause survives a restart. That points to a condition in configuration, the network, or the MySQL server rather than a hung process.

Does the connect URL reach MySQL from both gateway hosts?

A system that ran for a long time and then failed with no project changes almost always changed underneath the application. Common examples are a Windows update that reset firewall rules, a network profile that switched from Private to Public, a NIC or DHCP address change, or a MySQL service update that rewrote its configuration file. Match the driver message to a cause:

Test the TCP hop from each gateway host before touching any Ignition settings:

Test-NetConnection -ComputerName <mysql-host-ip> -Port 3306

Replace 3306 if the server listens on a non-default port; read it from the connect URL. A failed TCP test puts the fault in the network or the MySQL listener. A successful TCP test combined with a Faulted status puts it in authentication, the schema, or MySQL's limits.

Can one bad pooled connection fault a single client?

By default, Ignition opens eight connections to the database as a pool. A single broken connection inside an otherwise healthy pool is possible. However, the pool hands out whichever idle connection is available. That failure would therefore hit random requests from every client and from the Designer, not one client repeatedly. Treat this branch as the last explanation, reached only when the serving gateway shows Historique_Alarmes as Valid.

If you reach this branch:

1. In the connection's advanced settings, confirm that a validation query and connection testing are enabled. Stale sessions are then detected and replaced rather than handed to a query.
2. Re-save the Historique_Alarmes connection on the active gateway. This rebuilds the pool without a gateway restart.
3. Confirm the failing client runs the same project and window as the working client. Also confirm its Alarm Journal Table references the same journal profile. A journal profile pointed at a different datasource produces the same kind of message under a different connection name.

How do you clear the fault on a running vessel without a shutdown?

Operating time is limited, so do every read-only step first and make one targeted change.

1. Capture the redundancy state and the Historique_Alarmes status on both gateways.
2. Identify the gateway serving the failing client using the connected-client lists.
3. Copy the driver exception text from that gateway's log.
4. Run the TCP test from that gateway's host to the MySQL host and port.
5. Apply the single correction the driver message points to: URL host, account grant, firewall rule, bind address, or connection limit. Firewall rules and account grants take effect without restarting anything.
6. If the connect URL changes, edit the connection on the master so the configuration replicates to the backup. Then confirm the backup shows the new URL.
7. Do not force a redundancy failover to test the change during operations. A failover moves every client and the alarm pipeline at once. Validate on the standby node's status page instead.

How do you confirm the journal reads on both clients?

1. Both gateways show Historique_Alarmes as Valid on their Status pages, and each has held that state across several refreshes.
2. The gateway logs show no new fault entries for the connection after the change.
3. On the previously failing client, reopen the window with the Alarm Journal Table. Open Client Diagnostics and confirm no new WARN entries from Vision.Components.AlarmJournalTable.
4. Confirm the latest journal entry has the same timestamp on both Vision clients and in the Designer.
5. Trigger or wait for a new alarm event. Confirm it appears in the journal on both clients, including the client on the database PC.

FAQ