Hi all,
Running Ignition 8.1.44 with a SQL Server historian. Tag history queries return 0 rows with no error whenever the queried range doesn't contain an actual value change — the boundary/bounding value lookup isn't happening. In the Power Chart this shows up as Bad_NotFound. Widening the range until it touches a real stored row makes the query work, so writes are fine.
Root cause found so far:
• sqlth_drv has two entries for the same tag provider (ignition-pcmxpdwrpt01): id=1 with provider=NULL, and id=2 with provider=default. Presumably created when the provider identity string changed at some point. (Screenshot 1)
• All active tags are associated (via sqlth_scinfo) with drvid=2 — 78 sts_running tags, all under drvid=2, none under drvid=1. (Screenshot 2)
• sqlth_partitions only contains partition records for drvid=1 — and those are current, up to today's partition (July 17). Zero rows for drvid=2. (Screenshots 3 and 4)
• Reproducible in the Script Console: a 2-hour queryTagHistory on a tag that has stored history returns with no exception. (Screenshot 5)
So the partition manager keeps registering daily partitions under the old driver id, while queries for the tags filter partitions by the new driver id, find none, and skip the boundary lookup entirely. Data is physically present in the sqlt_data_1_* tables.
Questions:
1. Is there a supported procedure to consolidate the duplicated driver rows in sqlth_drv (or repoint sqlth_scinfo / partition records) without corrupting existing history?
2. As a stopgap, is it safe to duplicate the partition rows into drvid=2 (INSERT copies of the drvid=1 rows)? It seems purely additive, but I'd rather confirm before touching historian metadata.
3. Any known trigger for the duplicate driver creation (gateway rename, backup restore, upgrade) so we can prevent recurrence?
Happy to share more queries/screenshots. Thanks!
