Troubleshooting Ignition Alarm Journal DisplayPath Results

In Ignition 7.9.1, the alarm journal can show an empty DisplayPath while Source contains the provider, tag path, and alarm name in one qualified string. Check the journal record first: an unset or static display path is not stored in each record, so parsing Source or changing the query will not populate that database column.

Check the journal row before changing the script

Compare the same alarm event in the journal table and in the returned event list. Record the values for DisplayPath and Source, and confirm whether the display path is null or empty in the database. The example source has this form:

prov:default:/tag:Bays/Bay_1/Chiller Status:/alm:Chiller Faulted

This is a qualified source string carrying multiple alarm-source components. It is not evidence that the query moved three database fields into the Source column; the source already represents the alarm's qualified identity. First decide whether you need a stored display label, the tag path, the provider, or the alarm name. Those are different values, and the journal's DisplayPath field is not a guaranteed substitute for all of them.

Read the source components without splitting text

getSource() returns a fully qualified path. The returned source object provides built-in component accessors, so retrieve the provider and tag path by their component names instead of parsing delimiters. The alarm name is available separately through getName().

source = alarmEvent.getSource()
provider = source.getPathComponent("prov")
tagPath = source.getPathComponent("tag")
alarmName = alarmEvent.getName()

Use the object methods on the returned event rather than applying string operations to the sample source text. A tag name or path can itself contain characters that make ad hoc splitting brittle. Keep each value in its own application-level field if you need separate filtering or display.

1. Obtain one returned alarm event from the query.
2. Call getSource(), then call getPathComponent("prov") and getPathComponent("tag") on that source.
3. Call getName() on the alarm event for the alarm name.
4. Compare those values with the corresponding source components visible in the journal row.

If a component accessor is unavailable or returns an unexpected value in your runtime, inspect the actual object type and installed Ignition version before changing the component names or writing a parser.

Check whether the alarm has a stored display path

The journal's display path is a display-oriented value, not a mandatory copy of the normal tag path. When the display path is not configured, or is static, it is not stored in every journal record. The default journal entry for this field can be null. That explains why a query can return the alarm's source while the database's DisplayPath remains empty.

1. Open the alarm configuration for the tag that generated the event.
2. Check whether a display path is configured and whether it is static or varies with the event.
3. Compare the configured value with a newly generated journal record; do not expect an existing record to acquire a value just because a screen can render a path.

If the display path is unset or static, choose a data source that matches the requirement. For a tag-path filter, use the source's tag component. For a provider filter, use prov. For the alarm's configured name, use getName(). If the application specifically needs a persisted display label, configure and test that field's behavior rather than treating the source string as a replacement database column.

Separate the displayed label from the event identity

The source string carries provider, tag, and alarm context. The display path serves presentation, and it can be overridden. Those roles differ: one identifies the qualified alarm source; the other supplies a display value. A user interface can show a path even when the journal's DisplayPath column is null, so a status or history screen is not a reliable test of the database schema's populated values.

For SQL or downstream reporting, decide which semantic field the report needs before writing a select. Use DisplayPath only when the application expects the configured display value and accepts nulls. Use source components when the requirement is specifically the provider or tag path. Use the alarm name accessor for alarm name. Avoid making consumers parse the full Source text unless a component accessor is unavailable in the installed version and the source format has been validated for that version.

Check the runtime API before using the event accessor

In more recent Ignition versions, returned alarm-event objects provide getDisplayPathOrSource(). Use it to obtain the display-path-or-source value from the event list when that accessor exists in the installed runtime. Its name signals a fallback value; it does not turn a missing journal field into a populated DisplayPath database column.

The installation in the question is Ignition 7.9.1. Do not copy an accessor from a newer runtime into that installation without checking the scripting API available there. Check the runtime's API documentation or inspect the returned event object. If the accessor is unavailable, use the supported members for source and alarm name, and get the tag/provider from getSource() components.

Order the query before keeping five events

To return the five most recent entries, selection and ordering must agree. Trimming an unordered or oldest-first result to five does not guarantee the newest five. First verify the query's ordering and the timestamp or event-time field it uses; then apply the five-row selection using the query mechanism available in your Ignition installation.

1. Run the alarm-journal query without trimming and inspect the returned order and event timestamps.
2. Confirm that the first result is the newest event if your script keeps the first five; reverse the selection logic if the result is oldest-first.
3. Apply the five-entry limit only after confirming the ordering, or use a query-level limit and sort if the installed query interface supports both.
4. Check the final list for exactly the intended five events and compare them with the newest records in the journal.

The evidence does not specify a query function signature or sort parameter, so do not invent one. Keep the event objects in the result list if later code needs getDisplayPathOrSource(), getName(), or source-component accessors; reducing each result to a string too early discards those object methods.

Verify the field and result independently

Test the database representation and the user-facing result as separate checks. A correct screen label does not prove that DisplayPath is stored, and a correctly populated source does not prove that the list contains the newest five events.

1. Generate or identify a new event for an alarm with a known display-path configuration.
2. Inspect its journal row and record DisplayPath and Source independently.
3. Retrieve the event object and compare getName(), the provider/tag source components, and getDisplayPathOrSource() where supported by the runtime.
4. Check the ordered event timestamps and verify the five retained entries against the journal's newest records.
5. Repeat with an unset or static display path if that configuration is used, and confirm that the application handles a null journal display path without treating it as a query failure.

Stop changing the query when the database field is empty because the display path is unset or static; that branch is configuration/data semantics, not a result-trimming bug. If the supported event methods or journal behavior differ from the installed version's documentation, collect the Ignition version, alarm configuration, returned object values, and relevant journal rows, then escalate through Inductive Automation's official support channel.

FAQ