# Records Inserted Directly into alarm\_events Table Not Visible in Perspective Alarm Journal Table **URL:** \ **Category:** Ignition Exchange\ **Tags:** scripting, perspective\ **Created:** [June 3, 2026, 11:41pm UTC](https://forum.inductiveautomation.com/t/records-inserted-directly-into-alarm-events-table-not-visible-in-perspective-alarm-journal-table/115839 "2026-06-03T23:41:46Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![mike.pelletier](https://avatars.discourse-cdn.com/v4/letter/m/df788c/32.png) [@mike.pelletier](https://forum.inductiveautomation.com/u/mike.pelletier)\ **Post date:** [June 3, 2026, 11:41pm UTC](https://forum.inductiveautomation.com/t/records-inserted-directly-into-alarm-events-table-not-visible-in-perspective-alarm-journal-table/115839/1 "2026-06-03T23:41:46Z")
Hi all, I am working on a solution to log operator actions (tag writes) into the Ignition Alarm Journal for audit trail purposes. My approach is to insert records directly into the alarm\_events and alarm\_event\_data tables using a Named Query called from a Python script. The inserts are working correctly — I can see the records in the database using SSMS. However the records are not visible via system.alarm.queryJournal() or in the Perspective Alarm Journal Table component, even though Ignition-generated alarm records for the same tags appear without issue. **Here is what I have verified:** - My inserted records are structurally identical to Ignition-generated records in both alarm\_events and alarm\_event\_data - The source and displaypath values exactly match those written by Ignition for real alarms on the same tags, including the :/alm:Alarm suffix on the source path - The eventid is a randomly generated UUID via SQL NEWID() - eventtype, eventflags, and priority all match Ignition-generated records **My question is:** Why won't my custom and simingly valid alarm\_events and alarm\_event\_data table entries show up in the Perspective Alarm Journal table. Any guidance would be greatly appreciated! ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [June 4, 2026, 2:21am UTC](https://forum.inductiveautomation.com/t/records-inserted-directly-into-alarm-events-table-not-visible-in-perspective-alarm-journal-table/115839/2 "2026-06-04T02:21:20Z")
I would guess (but much more than a wag) that you are making untrue assumptions. For speed, I would expect Ignition to treat those tables as a **log** of events and details, not the primary source for further use. That is, Ignition is certainly **caching** events it inserts, and only queries the tables when data outside its memory model is requested. IIRC, journals participate in S&F, so the system would therefore **have to** work this way. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [June 4, 2026, 12:47pm UTC](https://forum.inductiveautomation.com/t/records-inserted-directly-into-alarm-events-table-not-visible-in-perspective-alarm-journal-table/115839/3 "2026-06-04T12:47:44Z")
My question is why aren't you using the built in audit logging that exists and automatically does this for you? There's no need to script this functionality. ---
**Author:** ![mike.pelletier](https://avatars.discourse-cdn.com/v4/letter/m/df788c/32.png) [@mike.pelletier](https://forum.inductiveautomation.com/u/mike.pelletier)\ **Post date:** [July 14, 2026, 5:10pm UTC](https://forum.inductiveautomation.com/t/records-inserted-directly-into-alarm-events-table-not-visible-in-perspective-alarm-journal-table/115839/4 "2026-07-14T17:10:21Z")
1. In my case the audit journal only logs things like "joe logged on/off", "joe saved view soAndSo" 2. Iteroperabilty with higher level enterprise software dictates that operator actions be logged in the alarm journal as Diagnostic alarms. ---
**Author:** ![mike.pelletier](https://avatars.discourse-cdn.com/v4/letter/m/df788c/32.png) [@mike.pelletier](https://forum.inductiveautomation.com/u/mike.pelletier)\ **Post date:** [July 14, 2026, 5:24pm UTC](https://forum.inductiveautomation.com/t/records-inserted-directly-into-alarm-events-table-not-visible-in-perspective-alarm-journal-table/115839/5 "2026-07-14T17:24:13Z")
> [@pturmel](#): > > not the primary source for further use As I'm sure you know, Perspective's Alarm Journal component displays the list of past alarms/events stored in whatever database you have your gateway configured for. I simply want to included operator tag writes events in the gateway alarm journal. This would allow supervisors to see who wrote what to which PLC tag from Ignition. But more importantly it is a requirement of higher-level enterprise software that generates reports from MS SQL tables and Canary historian. That part works fine BTW. I'm just trying to make those same events available in the Perspective Alarm Journal component. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 14, 2026, 5:51pm UTC](https://forum.inductiveautomation.com/t/records-inserted-directly-into-alarm-events-table-not-visible-in-perspective-alarm-journal-table/115839/6 "2026-07-14T17:51:03Z")
> [@mike.pelletier](#): > > I simply want to included operator tag writes Ignition does this in the **audit** subsystem, not in alarms. > [@mike.pelletier](#): > > displays the list of past alarms/events stored in whatever database Based on your OP, it actually doesn't, unless you ask it to show a timeframe that the alarm subsystem hasn't cached. 🤷‍♂️