I’m backing up and restoring a full solution spanning multiple server machines onto a new site. The plan is to deploy this solution and simply change some of the networking info for the new site. At the new site, I want to just delete all the tables in the database and let the new Ignition instance recreate tables to store all of the new site’s data.
So, the question is, what exactly triggers the feature in ignition whereby it automatically populates a database with tables? On learning this, I will delete all the existing tables in the database on the restored SQL server and trigger repopulation from ignition.
Did you find an answer to this? I’m troubleshooting an issue where the database tables were not created at all, despite having a valid database connection. I saw some posts that seemed to indicate the tables may get created when the module was restarted but that did not work for me.
Assuming this is all referring to the Tag Historian modules created tables (sqlth_ or sqlt_data_ prefix) then the tables will be recreated as soon as any source of historical data actually sends data to the tag history provider. Tag history providers are automatically created 1:1 with database connections - so as soon as any scan class fires to store history on a new DB the tables will be automatically generated.
That does not seem to have happened for me, tables are not created despite having a valid database connection and many tags configured to push history to this database.
I have posted a new topic here (link below) so as not to confuse this topic and the intent of the original poster. I would appreciate further feedback from you.
Hey, sorry for the late response. For that project, we tried a few different things, but were unable to find a way to predict when the tables would recreate. We eventually wrote a script that deleted all the contents of the tag history tables with dates prior to the install date at the new site, and that worked well for us.