# Historian Not Recognizing Manually Backfilled sqlt data

**URL:** <https://forum.inductiveautomation.com/t/historian-not-recognizing-manually-backfilled-sqlt-data/113168>\
**Category:** Ignition\
**Created:** [January 8, 2026, 9:37pm UTC](https://forum.inductiveautomation.com/t/historian-not-recognizing-manually-backfilled-sqlt-data/113168 "2026-01-08T21:37:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![sam8](https://avatars.discourse-cdn.com/v4/letter/s/b5e925/32.png) [@sam8](https://forum.inductiveautomation.com/u/sam8)\
**Post date:** [January 8, 2026, 9:37pm UTC](https://forum.inductiveautomation.com/t/historian-not-recognizing-manually-backfilled-sqlt-data/113168/1 "2026-01-08T21:37:49Z")

</div>

Hi All,

I am facing an issue after back populating data into the current month partition sqlt\_data\_1\_2026\_01 table.  
Recently I migrated the site server from:  
Ignition 8.1 on Windows 11 → Ignition 8.3 in Docker Container on Linux Server  
Historian MS SQL Express 2019 → Timescale db Postgress in Docker Container on Linux Server

After the data migration all of the data from 2025 and earlier is viewable in the Historian Trends.  
However for the current month/partition after doing a manual import into pgAdmin the data for the current month and when the server went live and started logging is not showing in the trends.  
I have tried multiple gateway restarts to try get it to refresh the partition table.  
The partition table itself looks good with the start and end time for the Jan partition lining up.  
Is there some cache for the current month partition that I am missing?  
Any help much appreciated.

An example of one of the trends below note the data missing between 1st Jan and when the server went live.

 ![Screenshot 2026-01-09 103800](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/2/f28706399b491f5ed140f547d0babb559bcb623b.jpeg)

---

<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:** [January 8, 2026, 10:48pm UTC](https://forum.inductiveautomation.com/t/historian-not-recognizing-manually-backfilled-sqlt-data/113168/2 "2026-01-08T22:48:58Z")

</div>

Did you change the Ignition gateway name? That is part of the tuple that uniquely identifies tags in history.

---

<div class="post-metadata">

**Author:** ![sam8](https://avatars.discourse-cdn.com/v4/letter/s/b5e925/32.png) [@sam8](https://forum.inductiveautomation.com/u/sam8)\
**Post date:** [January 8, 2026, 11:11pm UTC](https://forum.inductiveautomation.com/t/historian-not-recognizing-manually-backfilled-sqlt-data/113168/3 "2026-01-08T23:11:35Z")

</div>

No the gateway name has not changed.  
However I did change the Tag Historian DB name from:  
”SQLServer” to “History” to be more a more logical name (Unsure why the original contractor named it that).

Does the row order of entries within the sqlt table matter?  
I have run a few queries to check that as row number is ascending t\_stamp is also ascending.  
as far as I can see it looks good.

 ![Screenshot 2026-01-09 120926](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/a/da521497ccd9f8d9ed2dcbb02adee1e96b42bede.jpeg)

---

<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:** [January 9, 2026, 12:12am UTC](https://forum.inductiveautomation.com/t/historian-not-recognizing-manually-backfilled-sqlt-data/113168/4 "2026-01-09T00:12:35Z")

</div>

Well, the tag history provider (DB name for normal providers) is the other unique part of driver ID tuple. So yes, changing the DB connection name broke your setup.

You can probably alter the metadata entries (while the gateway is shut down) to fix this. Take good backups.