Skip to end of metadata
Go to start of metadata


Overview

Ignition has a lot of systems built in that will query the database automatically without requiring you to build a query. These systems automatically create the necessary tables in the database, insert the relevant data, and even query it back out for you. However, because this data is all stored in simple database tables, it can be manually accessed using queries to customize how you see the data.

These tables are setup in very specific ways that the system understands. Altering them in any way may make it so the system can no longer automatically interact with the tables. While it can be useful to manually query out the data, we advise caution when attempting to alter the data or tables in any way. We recommend taking a backup of the database tables before making manual changes to them, with the understand that manually altering the data or tables is done at your own risk.

On this page ...

Tag History

The Tag History system utilizes six different tables in the database:

Table NameTable DescriptionColumn References
sqlt_data_x_x_xThis table stores the raw Tag data. There will be multiple tables that fit this format depending on the name of the Gateway and the date. (sqlt_data_1_2018_01 This table is storing data from the Gateway with an id of 1, for the year 2018, for the month of January)sqlt_data_x_x_x.tagid = sqlth_te.id
sqlth_teThis table stores the non-data details of each Tag.sqlth_te.scid = sqlth_scinfo.id
sqlth_scinfoThis table stores scan class information.sqlth_scinfo.drvid = sqlth_drv.id
sqlth_sceThis table stores start and end times for scan classes.sqlth_sce.scid = sqlth_scinfo.id
sqlth_partitionsThis table stores start and end times for each sqlt_data table.sqlth_partitions.drvid = sqlth_drv.id
sqlth_drvThis table stores information about the drivers of the historical data.none

See the Tag History Tables Reference for more information regarding all of the columns in the tables.


Alarm Journal

The Alarm Journal system utilizes two different tables in the database:

Table NameTable DescriptionColumn References
alarm_events*

This table stores every event (active, cleared, acknowledged) that happened to any alarms that fit within the Journal filter parameters. Each row is a new event

alarm_events.id = alarm_event_data.id
alarm_events_data*

This table stores unique information pertaining to each event. Each row is a specific property of a specific event, so alarm events with multiple properties will have multiple rows in the table.

none

See the Journal Properties and Tables page for more information regarding all of the columns in the tables.

*The names of the tables are completely configurable in the Journal settings in the Gateway. The default table names are used in the table.


Authentication

The Database Authentication system utilizes six different tables in the database:

Table NameTable DescriptionColumn References
scada_users*

This table stores each user contained within the user source, along with basic user information. Each row is a new user.

none
scada_roles*This table stores all of the possible roles within the user source. Each row is a new role.none
scada_user_rl*This table stores a mapping of users to roles. Each row is a user and a paired role, so users with multiple roles will have multiple rows in the table.

scada_users_rl.user_id = scada_users.id

scada_users_rl.role_id = scada_roles.id

scada_user_sa*This table stores a list of all upcoming schedule adjustments for each user. Each row is a new schedule adjustment, so users with multiple schedule adjustments will have multiple rows in the table.scada_user_sa.user_id = scada_users.id
scada_user_ci*This table stores a list of all contact information items for each user. Each row is a new contact information item, so users with multiple contact information items will have multiple rows in the table.scada_user_ci.user_id = scada_users.id
scada_user_ex*This table stores a list of all extra properties for each user, with properties and values stored 1 for 1. Each row is a new property and value pair, so users with multiple extra properties will have multiple rows in the table. Extra properties are added be modules that want to associate data with a user, such as the Voice Notification Module, which adds a Security PIN setting.scada_user_ex.user_id = scada_users.id

*The prefix of the tables are configurable in the User Source settings in the Gateway. The default prefix of "scada_" is used in the table


Audit Log

The Audit system utilizes one table in the database:

Table NameTable DescriptionColumn References
AUDIT_EVENTS*This table stores each auditable event (save, publish, edits, etc.) that has happened for each project or system that has auditing enabled. Each row is a new event.none

*The names of the tables are completely configurable in the Audit settings in the Gateway. The default table names are used in the table.



 

  • No labels