# Strange behavior with partitioned historian data tables **URL:** \ **Category:** Ignition\ **Created:** [November 10, 2017, 8:10pm UTC](https://forum.inductiveautomation.com/t/strange-behavior-with-partitioned-historian-data-tables/15964 "2017-11-10T20:10:18Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Bob](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bob/32/16899_2.png) [@Bob](https://forum.inductiveautomation.com/u/Bob)\ **Post date:** [November 10, 2017, 8:10pm UTC](https://forum.inductiveautomation.com/t/strange-behavior-with-partitioned-historian-data-tables/15964/1 "2017-11-10T20:10:18Z")
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, Bob ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [November 10, 2017, 8:22pm UTC](https://forum.inductiveautomation.com/t/strange-behavior-with-partitioned-historian-data-tables/15964/2 "2017-11-10T20:22:32Z")
`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. ---
**Author:** ![Bob](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bob/32/16899_2.png) [@Bob](https://forum.inductiveautomation.com/u/Bob)\ **Post date:** [November 10, 2017, 8:29pm UTC](https://forum.inductiveautomation.com/t/strange-behavior-with-partitioned-historian-data-tables/15964/3 "2017-11-10T20:29:17Z")
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 ---
**Author:** ![giulianacaula](https://avatars.discourse-cdn.com/v4/letter/g/779978/32.png) [@giulianacaula](https://forum.inductiveautomation.com/u/giulianacaula)\ **Post date:** [December 1, 2017, 8:10pm UTC](https://forum.inductiveautomation.com/t/strange-behavior-with-partitioned-historian-data-tables/15964/4 "2017-12-01T20:10:09Z")
> [@paul-griffith](#): > > sqlth\_drv 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 ?? Thanks,