# System.tag.queryTagHistory() doesn't work with Imported Data

**URL:** <https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147>\
**Category:** Ignition\
**Tags:** scripting\
**Created:** [May 12, 2025, 3:25pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147 "2025-05-12T15:25:05Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\
**Post date:** [May 12, 2025, 3:25pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/1 "2025-05-12T15:25:05Z")

</div>

Hi,

I have a test gateway that I am using to see how my one of my report scripts run with production gateway data. This test gateway is copy of a production gateway, so all its tags were imported with the project as well as the tag history.

When I run `System.tag.queryTagHistory()` to test the data grab:

```python
start = system.date.parse('April 1, 2025 00:00','MMMM dd, yyyy hh:mm')
end = system.date.parse('April 30, 2025 00:00','MMMM dd, yyyy hh:mm')
path = '[EHS]EHS/B2 Permit/Incoming Water/CH00243/Total'
history =system.tag.queryTagHistory([path],startDate=start, endDate= end, ignoreBadQuality=True,noInterpolation=True)
print(history.getRowCount())

```

I get a row count of 0.

However, when I search for the same tag path ` '[EHS]EHS/B2 Permit/Incoming Water/CH00243/Total'` in the` sqlth_te` table I find 3 tags:

 ![{8C8FFC6C-1345-49E4-8C2B-C3FA9C1CBE60}](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/1/d1258c241e148705fed958fca7b957f2db4f2cd9.png)

I then go and check that see if any of the IDs associated to the tagpath have data in the table `sqlt_data_1_2025_04` . Of the 3 IDs associated with the tag path, only one has data in the table, this being ID 1951.

 ![{DB852E1E-7476-4EDA-8901-800A11B3C839}](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/c/4c9b70c6717ca08bfefe09dfa51eaa7b1034d396.png)

So I am sure the data is present in the system, and so something is happening when I try to grab it.

This situation is the same across all the tags. There are 3 IDs per tag path, with only one of them, the second one, having data.

Things I've tried to fix this:

1. Setting the newest ID to retired in the `sqlth_te` table so that the second tag will be referenced when calling the `system.tag.queryTagHistory()`. This did nothing.

2. Change the SCID of the row that has the ID corresponding to data to the SCID that corresponds the newest ID for the tag of interest. This did nothing.

3. Change the SCID of the row that corresponds the newest ID to the SCID that corresponds the row that contains the ID that has data in `sqlt_data_1_2025_04`. This did nothing.

I am not sure where to go from this point. I was attempting to use this as reference: [Ignition Database Table Reference](https://www.docs.inductiveautomation.com/docs/8.1/appendix/reference-pages/ignition-database-table-reference#schema_info)  
so that I could manipulate the system to access the correct ID and/or partition for a tag, but I can't seem to figure it out.

Any suggestions? Thank you

---

<div class="post-metadata">

**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\
**Post date:** [May 12, 2025, 3:31pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/2 "2025-05-12T15:31:52Z")

</div>

I'd first check why you have 3 entries with the same tag path. Compare with your production DB, see if you observe the same thing.  
The difference in scid means that this tag's group has been changed, but having several entries for the same tagpath, with none of them being retired, seems very weird to me.

---

<div class="post-metadata">

**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:** [May 12, 2025, 3:36pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/3 "2025-05-12T15:36:03Z")

</div>

> [@Slick](#):
>
> This test gateway is copy of a production gateway, so all its tags were imported with the project as well as the tag history.

Tag history checks gateway names. If your copied gateway has a different name, then you have to fix all the history records to match.

---

<div class="post-metadata">

**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\
**Post date:** [May 12, 2025, 4:59pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/4 "2025-05-12T16:59:00Z")

</div>

Unfortunately I don't have access to production server backend. If I were to start over and have someone re-import the historical data from production while keeping the original tags in the test server, how would you do it and would it be a fix?

---

<div class="post-metadata">

**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\
**Post date:** [May 12, 2025, 5:11pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/5 "2025-05-12T17:11:08Z")

</div>

I tried this and it unfortunately did not cause `system.tag.queryTagHistory()` to grab the data. Let me show you a deeper dive into my tables, maybe this will provide some insight:

`Sqlth_te` when I run it for one tagpath:

 ![{C13AD955-7207-4C19-91EF-8B05F07999F4}](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/a/dafae6c6b32dd0789ff17b697302171e5c6b2225.png)

As you can see _scid_ = 1

`sqlth_scinfo`:

 ![{C63B36C8-FDED-45C4-8A6B-4C12690CDAB7}](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/b/bb9373366741f35611c6dc2c7979a7b2396b60b7.png)

`sqlth_drv:`  
Note I colored out the _name_ column but I can confirm it's the name of the test server gateway.

 ![use](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/4/b49a5b754be782d8530ece8f65947b82d4aeca4a.png)

`sqlth_partitions`:  
Notice how there is a sqlt\_data\_3\_2025\_05. This has some data in it as well. I don't really know where it came from. Maybe the system created it for the tags in my test gateway and that is why I can't access the other partitions. However since I've changed _drvid_ to `drvid = 1` so that the `scid = 1` traces to the correct partitions, I don't think causing the problem.

 ![{E1F51BDB-6349-4948-B9D7-BCF937FDF8A8}](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/c/6cd31513909184e1eb9fc89437d6d0cd326a54c5.png)

Should I just try to have the data reimported into the test server? If so, what should I look out for so that this problem doesn't occur again?

Thank you

---

<div class="post-metadata">

**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:** [May 12, 2025, 5:17pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/6 "2025-05-12T17:17:09Z")

</div>

Have you restarted after editing the metadata? (The historian subsystem caches this stuff.)

---

<div class="post-metadata">

**Author:** ![Nol](https://avatars.discourse-cdn.com/v4/letter/n/8e8cbc/32.png) [@Nol](https://forum.inductiveautomation.com/u/Nol)\
**Post date:** [May 12, 2025, 9:01pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/7 "2025-05-12T21:01:40Z")

</div>

Try going to your \_drv table, duplicate your first line but put id=2 then put the first line's provider as NULL instead. Then alter \_scinfo and set both drvid entries to be 2.

---

<div class="post-metadata">

**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\
**Post date:** [May 13, 2025, 12:27pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/8 "2025-05-13T12:27:20Z")

</div>

I tried this but I am still getting 0 from:

```python
history =system.tag.queryTagHistory([path],startDate=start, endDate= end, ignoreBadQuality=True,noInterpolation=True)

print(history.getRowCount())

```

I tried some other tag paths just as a sanity check and its 0 for those as well.

---

<div class="post-metadata">

**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\
**Post date:** [May 13, 2025, 12:27pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/9 "2025-05-13T12:27:51Z")

</div>

Yes I have, it doesn't make a change.

---

<div class="post-metadata">

**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\
**Post date:** [May 13, 2025, 10:11pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/10 "2025-05-13T22:11:23Z")

</div>

I have discovered why I have 3 entries with the same tag path for all my paths. Originally, the production server only has two per path, with one being retired. However, when this data was imported into my test server, the _name_ column of `sqlth_drv` contained the production server's name, not the test server's. This caused a third ID/entry to be created in `sqlth_te` for all the tags in the test server that have history enabled, with these new entries having a _scid_ = 2 rather than _scid_ =1. Additionally, new `sqlth_drv` entries were automatically created with the _name_ column being the test server name this time. Furthermore, a new partition was created for May historical data. All my partition tables are titled `sqlt_data_1_2025_xx`, but this new one has a partition of `sqlt_data_3_2025_05`. After figuring this out I thought I could simply change the _name_ column of `sqlth_drv` to the test gateway name for all entries, change the _scid_ of the entries to 1 in `sqlth_te`, retire entry containing previous ID in `sqlth_te`, and lastly change the entries in my partition tables so that old IDs are changed to the new ones that were automatically created. This however did not work ☹ .

Do you have any recommendations on what to do? If I have the data re-imported but with the correct test gateway name in `sqlth_drv` will I have this problem again? Can I fix the issue without reimporting?

---

<div class="post-metadata">

**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:** [May 13, 2025, 10:12pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/11 "2025-05-13T22:12:48Z")

</div>

> [@Slick](#):
>
> the _name_ column of `sqlth_drv` contained the production server's name, not the test server's

Hmmm. Sounds familiar.... 🤷‍♂️

Consider opening a support ticket so IA can look over your shoulder. No telling how scrambled your data is.

---

<div class="post-metadata">

**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\
**Post date:** [May 13, 2025, 10:25pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/12 "2025-05-13T22:25:29Z")

</div>

Will do, thanks! If I do decide to just have the data reimported, but with the correct gateway name (test gateway name) in `sqlth_drv`, would this however fix my issue?

Also thinking back on your question about restarting, what do you mean exactly? I don't have capabilities to reset the gateway as decribed in this doc: [Gateway Command-line Utility - gwcmd](https://www.docs.inductiveautomation.com/docs/8.1/platform/gateway/gateway-command-line-utility-gwcmd)

However I can save the project on the gateway in the designer which does show some restart information in the logs:  
 ![{71B29E96-06C1-42DF-9147-A59C752E7A63}](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/0/1020f553c4b0475b03458fb33ecd4c0e7e60f74b.png)

Additionally, when I close out of the project on designer, then re-login into my test gateway (or any gateway), I can see that my projects are loading on the gateway.

Do either of these count as restarts?

---

<div class="post-metadata">

**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:** [May 13, 2025, 10:26pm UTC](https://forum.inductiveautomation.com/t/system-tag-querytaghistory-doesnt-work-with-imported-data/106147/13 "2025-05-13T22:26:42Z")

</div>

> [@Slick](#):
>
> would this however fix my issue?

Should, yes.

> [@Slick](#):
>
> Do either of these count as restarts?

No. You have to restart the gateway service or the whole machine.

I probably should have pointed you here:

> [@Tag History Migration Best Practices? Upgrading to new servers!](https://forum.inductiveautomation.com/t/tag-history-migration-best-practices-upgrading-to-new-servers/75766):
>
> In the middle of a shutdown and was wondering if any of you had any tips for migrating to a new database on a separate server than the gateway. My greatest concern is keeping the Tag History intact. Plan is to upgrade from 7.9.10 to 8.1.x. Currently our database (MySQL) is on the primary gateway. We have a lot of tag history that is getting stored to a database/schema called 'ignition' in MySQL. It's fairly straightforward. We've be given the opportunity to have a separate database server …
