Strange behavior with partitioned historian data tables

I believe this situation was caused after importing tags from an XML file in the Ignition designer.

Prior to importing the tag XML file, there had already been a table: sqlt_data_1_2017_11. After importing the tags XML file, a new table was created: sqlt_data_3_2017_11. There was no table: sqlt_data_2_2017_11.

We do this operation all the time and I have never seen this behavior. Not sure why a new table was created at all, and then to skip “2” was even stranger. What tipped this off was that we had new data being collected, yet when looking at our Ignition project windows I was not seeing the new data. I later found the reason was that it was being stored in sqlt_data_3_2017_11, while historical queries running in our Ignition project were still going against the table sqlt_data_1_2017_11. Therefore the last record we would get when looking at our Ignition project windows was the last record that was stored in the table sqlt_data_1_2017_11.

This was seen at a new installation at a customer site and I had remote access to the system. Since the customer did not mind losing data, I sopped the Ignition Gateway, deleted all Ignition historian tables (all sqlt… tables) and restarted the Gateway and all tables were recreated and the system was working fine.

But I am afraid this can happen again and am wondering if anyone else has seen this issue, or can give a possible explanation for what happened with the new partition table?

Ignition v7.9.2

Historical tag provider options:

Partition Lenth: 1
Partition Units: Months
Enable Pre-processed Partitions: No
Enable Data Pruning: No

Thank you,

sqlt_data_3 would indicate that a new entry was created in the sqlth_drv table; meaning that the historian though a new gateway was connected to the system. sqlth_drv will have (at minimum) two entries for each gateway; one with no provider, and one for each realtime tag provider that’s storing history into that gateway. So if you had gatewayA with null and default, (drvid 1, 2) and the system thought that an additional gateway was logging history (gatewayB, with null and default) then it would create a new sqlt_data table to separate the data from the gatewayA from the data coming from gatewayB.

I don’t know why that would have happened on a tag import, but that’s definitely what the system thought it was doing.

1 Like

Ok, I see what you are saying. And although I’m still not sure why it would have thought an additional Gateway was logging history, at least it gives me something to think about. You also explain why I shouldn’t expect to see sequential table names:
“sqlt_data_1…”, “sqlt_data_2…”, “sqlt_data_3…”

Thank you

I have the same issue.

I had made a migration of servers and had to install everithing (gateway, database, etc) in a new computer server, so I restore the previous database and didn’t realice that in the sqlth_drv table was already the old server name.
The thing is that the client use this table todo some other stuff, so they need the table called sqlt_data_1, not sqlt_data_3.

My question is the following. If I delete thoese records of the database, I mess everything up? Or the next month it will start with sqlt_data_1 ??