A blank or unexpectedly sparse trend usually points to the history path, not to a compression setting: Ignition’s SQLTags Historian records changes per tag, while a historical group can write every member when any one member changes. Trace the displayed result back through the tag and historian configuration to the database before changing storage settings.
What does the trend or history screen show?
First distinguish “no history” from “fewer rows than expected.” A trend with no usable values may reflect a failed history database connection, a missing database schema, or insufficient database privileges. A trend that has values but fewer samples than a historical group produced may reflect the historian’s per-tag, on-change behavior.
| Screen or database observation | Likely area to inspect | Next check |
|---|---|---|
| History database connection is faulted | Database connection, schema, account privileges, or name casing | Inspect database configuration and connection diagnostics; then verify the schema and account access. |
| A tag has history, but fewer rows than a historical group | Different recording behavior | Compare the historian’s per-tag on-change logging with the group’s logging behavior. |
| Some tags are missing while others record | Tag history configuration or tag-specific behavior | Check the affected tags individually and compare their history settings and value changes. |
| Data exists but is spread across time-based tables | Historian partitioning | Identify the relevant partition before concluding that data is missing. |
A plotted line alone does not prove that every expected sample was stored. Compare a tag’s actual value changes with the database rows for its history interval. If the connection is faulted, resolve that path before diagnosing sampling behavior.
Does SQLTags Historian compress data?
The described storage reduction comes from recording changes on a per-tag basis. That is a data-selection behavior, not evidence of a separate compression algorithm. A tag that does not change does not generate the same repeated records as a group that writes all its members whenever any one member changes.
With a historical group in asynchronous mode, the described behavior is to log all items when any item in that group changes. If one member changes often and the other members remain steady, the group can therefore store repeated values for the steady members. SQLTags Historian’s per-tag on-change behavior avoids those group-wide writes. The difference is most relevant when grouped tags change at different rates.
Do not interpret “on-change” as a promise about byte-level compression, a particular deadband, or a specific database engine. To determine which value changes qualify for storage, inspect the history settings for the tag in the installed Ignition version. To assess actual disk savings, compare database storage and row counts under equivalent tag activity and retention periods.
Should you use SQLTags Historian or a historical group?
Choose based on the behavior the application needs, rather than assuming the two methods produce equivalent rows. Per-tag recording suits independent tag histories where each tag should add data when it changes. A historical group can be appropriate when the application uses its group-based collection behavior, but the all-members-on-any-change behavior can produce more records.
| Method | Recording behavior described | Engineering consequence |
|---|---|---|
| SQLTags Historian | On-change, per tag | One tag changing does not, by this description, force a write for every other tag. |
| Historical group, including asynchronous mode | When one item changes, all items in the group are logged | Unchanged group members can receive repeated records. |
Before switching methods, check consumers of the history: charts, trends, and queries may rely on the existing data layout or sampling pattern. A change in recording method affects the rows produced, so validate the result in the actual visualization and any downstream query.
Does a database fault point to the driver or controller?
A faulted database connection is on the history storage path. Trace the value from the operator display to the tag, then from the tag’s history configuration to the database connection. If the live tag value is updating but the history database connection is faulted, investigate the storage connection rather than treating the symptom as a controller or field-driver failure. If the live value itself is stale or faulted, check the tag’s source and its driver/controller path separately.
For a MySQL connection, the described setup requires a database schema to exist before Ignition connects; Ignition does not create that schema. The database account also needs the privileges required for historical SQLTags operations. On Linux, table-name references can be case-sensitive, so compare the configured names with the actual database names exactly. A connection test that reaches MySQL does not by itself verify schema access, write privileges, or correct table naming.
Where do partitions and timestamp storage fit?
SQLTags Historian is described as creating time-based data tables automatically, regardless of the underlying database. This is Ignition-managed partitioning; it is not the same mechanism as configuring native MySQL partitions. Do not apply a MySQL partition-count limit or day/week partition plan as though it governed Ignition’s own table creation.
Historical timestamps are described as stored as long integers for index-performance reasons. That implementation detail does not mean the historian uses a compression format. When investigating missing intervals, identify which time-based table contains the target time range instead of expecting all historical rows in one table.
Database archive engines are a separate storage option. The discussion describes converting data tables to MySQL’s Archive engine as possible, and mentions automatic table-creation parameters and maintenance for merging older partitions as planned functionality at that time. Treat those statements as version-dependent, not a current capability guarantee. Check the installed Ignition and database documentation before choosing an engine or planning partition maintenance.
How do you isolate and resolve a history fault?
- Read the operator symptom. Note whether history is absent, sparse, or merely located in older time-based tables. Check whether the live tag value is updating.
- Separate source from storage. If the live value is also bad, inspect the tag source and driver/controller path. If the live value is good but history is missing, continue along the historian-to-database path.
- Check the history setup. Confirm that the affected tag is configured for historical logging and determine whether it uses SQLTags Historian or a historical group. Compare the expected record pattern with the method’s behavior.
- Inspect the database connection. Read the connection fault details and verify that the named database schema already exists. Confirm that the configured database account can perform the operations required for historical logging.
- Check exact names on Linux. Compare configured table or schema references with database names, including letter case. Correct mismatches before retesting.
- Locate the time range. Account for automatically created time-based tables when querying history; do not assume that Ignition’s partitioning is native MySQL partitioning.
- Retest with a changing tag. Restore the database path, generate or observe a real tag value change, then inspect the plotted history and stored record. Compare the result with the selected historian or group behavior.
The manual location identified for the historian mechanics is Gateway Configuration > SQLTags, in the How SQLTags Historian Works section. Use the manual matching the installed version for configuration names and database requirements; do not rely on roadmap statements from another release.
FAQ: What happens if history behaves differently than expected?
What happens if one tag changes in a historical group?
The described asynchronous group behavior logs all items when any one item changes. That can create repeated rows for unchanged group members.
What happens if a SQLTags Historian tag does not change?
Per-tag on-change logging does not produce the same group-wide write merely because another tag changes. Check the tag’s configured history behavior and actual value changes when validating the result.
What happens if Ignition says the MySQL connection is faulted?
Check that the schema already exists, the account has the required history privileges, and configured names match the database names exactly. On Linux, case differences in table references can matter.
What happens if historical rows are in another table?
SQLTags Historian is described as automatically creating time-based tables across underlying databases. Identify the partition containing the interval, then verify the displayed trend against that table and the tag’s recording method.
Final verification: confirm that the live tag changes, the database connection is healthy, and a new history record for that change appears in the expected time-based table and in the trend.