Hi! I have an issue regarding the Default historian tag. I configured the History tag to save the data to a MySQL database. I have configured the data partionining so that the tag would create a new table every day and store data in it every day. It seemed to work fine for some time until yesterday (9th of October) when the data was still written to the previous day table (8th of October). I checked that the system and gatewaye date / time are the same so I don't think that is the issue. I could solve it eventually by changing the partition units to 1 min and then back to 1 day. At this point it created the corresponding 1 min table as well as the 1 day table for 9th of October.
However my question is what happened there and how can one avoid this in the future?
Ignition's history tables are aligned to whatever the partition unit is from when the system starts up/first stores history. They don't go backwards or forwards to align to arbitrary "wall clock" times, which would invite problems with timezones and the like.
In other words,
If you start a system with daily partitions on 2024-10-9 at 13:28 local time,
I would not expect your next "daily" partition until 2024-10-10 at ~13:28 local time.
You can look in the sqlth_drv table to see the unix timestamps assigned to each table partition - those are what actually matters, not the name assigned to the table.
While there are ways to force the system to align with your expectations, I would recommend you don't, for the simple reason that you shouldn't care. The only supported way to query data out of the historian is via Ignition, and we will automatically bridge across as many tables as needed. Partitioning by arbitrary 24 hour slices will still segment the data and lead to approximately the same table sizes.
Thanks for the reply!
I will then try to check again in 24 hours after having started my system and check if the new table has been created. Will come back with details.