system.tag.storeTagHistory() appears to corrupt sqlth_partitions metadata when backfilling historical data

Ignition
, ,
1

I'm attempting to backfill history for a newly-created Dew Point tag.

System Architecture

  • Ignition 8.1.x (currently 8.1.53)
  • HVAC system with Temperature and Relative Humidity historized for several months
  • Dew Point was recently added as an expression tag
  • The tags reside on a remote Edge gateway (tp_lpsd)
  • The Historian is configured only on the central gateway

My goal is to export Temperature and RH history, calculate Dew Point, and backfill the Dew Point history. The export and calculation stages are complete.

Initial Test

Before importing several months of data, I attempted to insert a single historical point from 2020 using the following script:

testDate = system.date.parse("2020-01-02 12:00:00", "yyyy-MM-dd HH:mm:ss")

system.tag.storeTagHistory(
    "Edge Historian",
    "tp_lpsd",
    ["EP/KK/HVAC/BH5562/SpaceDewPoint/PV"],
    [99.99],
    [192],
    [testDate]
)

The call succeeded and I confirmed the data existed in the historian partition table.

However:

  • The point was not visible in trends
  • system.tag.queryTagHistory() could not retrieve the point

Tag Creation Date Investigation

The Dew Point tag's entry in sqlth_te had a creation date after the historical timestamp being inserted.

I updated the created timestamp in sqlth_te using a SQL update statement to a date in 2019 and restarted the gateway.

The inserted point was still not visible via trends or queryTagHistory().

Partition Metadata Investigation

While troubleshooting, I found the following entries in sqlth_partitions:

sqlt_data_4_2020_01,4,1577854800000,1577858399999,0,null
sqlt_data_4_2020_01,4,1577858400000,1577858399999,0,null

Observations:

  • Every other monthly partition has a single entry spanning the full month. Note: The dual entry for March was created when I tried to reproduce the error. 
    • sqlt_data_4_2020_01,4,1577854800000,1577858399999
sqlt_data_4_2020_01,4,1577858400000,1577858399999
sqlt_data_4_2020_02,4,1580533200000,1583038800000
sqlt_data_4_2020_03,4,1583038800000,1583042399999
sqlt_data_4_2020_03,4,1583042400000,1583042399999
sqlt_data_4_2020_04,4,1585717200000,1588309200000
sqlt_data_4_2020_05,4,1588309200000,1590987600000
sqlt_data_4_2020_06,4,1590987600000,1593579600000
sqlt_data_4_2020_07,4,1593579600000,1596258000000
sqlt_data_4_2020_08,4,1596258000000,1598936400000
sqlt_data_4_2020_09,4,1598936400000,1601528400000
sqlt_data_4_2020_10,4,1601528400000,1604206800000
sqlt_data_4_2020_11,4,1604206800000,1606798800000
sqlt_data_4_2020_12,4,1606798800000,1609477200000
  • This partition now has two entries.
  • The first entry spans approximately one hour.
  • The second entry has start_time > end_time which creates a time span of -1. The second entry appears to have a valid starting date (1ms beyond first entries end date).
  • The underlying partition table contains approximately 31 million rows covering the entire month.

Querying the partition table confirms the actual data range spans nearly the entire month:

SELECT MIN(t_stamp), MAX(t_stamp) FROM sqlt_data_4_2020_01

1577854800000
1580533140000

Gateway Logs

At the time of the test insert, the following entries appeared in the gateway logs:

PartitionManager
21Aug2026 07:26:35
Historian Closing previous partition 'sqlt_data_4_2020_01'

PartitionManager
21Aug2026 07:26:35
Historian Created Tag history partition sqlt_data_4_2020_011

Additional Testing

I modified the timestamp of the inserted row to fall within the first partition range using a SQL update statement. After doing so:

  • queryTagHistory() successfully returned the point
  • The point became visible on historical trends

This suggests the Historian is honoring the partition metadata boundaries.

Reproduction

To determine whether this was specific to January 2020, I repeated the test in March 2020 after moving the tag's created date back. Before doing so, I verified that all of the March 2020 partition's looked normal.

The same behavior occurred.

The partition metadata changed from:

sqlt_data_4_2020_03,4,1583038800000,1585717200000

to

sqlt_data_4_2020_03,4,1583038800000,1583042399999
sqlt_data_4_2020_03,4,1583042400000,1583042399999

and the logs showed:

PartitionManager
24Aug2026 09:19:01
Historian Closing previous partition 'sqlt_data_4_2020_03'

PartitionManager
24Aug2026 09:19:01
Historian Created Tag history partition sqlt_data_4_2020_03

Questions

  1. Is this expected behavior when using system.tag.storeTagHistory() to backfill data before the original historized creation date of a tag?

  2. Why is the Historian recreating the partition metadata with:

    • a one-hour partition
    • a second partition whose start_time is greater than its end_time?

  3. Is it safe to manually repair sqlth_partitions by:

    • deleting the invalid row
    • restoring the original month-long end_time

  4. What is the recommended method for backfilling several months of history for a newly historized tag without causing partition metadata changes?

Additional Historical Context

One other detail that may be relevant:

The Ignition system was commissioned around 2023. However, historical data exists back to 2018 because data from a legacy Wonderware Historian was imported into Ignition.

Unfortunately, I do not know the exact import methodology that was used. My understanding is that the migrated history was likely inserted directly into the historian database using SQL rather than through normal Ignition historian collection processes, but I have not been able to verify that.

Because of this, I cannot rule out the possibility that the existing partition metadata may have been affected by the earlier Wonderware migration. However:

  • The partition metadata issue was reproduced in multiple months (January 2020 and March 2020).
  • The behavior occurs immediately following a system.tag.storeTagHistory() call.
  • Corresponding PartitionManager log entries show Ignition closing and recreating the affected partition.

For those reasons, I'm trying to determine whether the migration history is merely coincidental or whether storeTagHistory() is interacting poorly with migrated historian partitions.