I recently split up a gateway into 2 into frontend/backend gateways. It was a few weeks ago now, but I must have just imported the original gateway into both and then deleted stuff from each. I’m guessing that a whole bunch of stuff is still stored inside the config.idb (like tag info in the frontend gateway which shouldn’t be there) because they’re both still ~220MB.
What’s the best method to purge out this config? I presume the answer is going to be to add the modules back and then manually delete the stuff from them to then delete it from the config. (In which case, something learnt for next time: start the gateways from scratch and import stuff in!)
You carried these backups over from a 7.9 or earlier system?
You can confirm with sqlite_analyzer (highly recommend) but it’s extremely likely that the table using almost all of that 220mB is PROJECT_CHANGES. That table is completely ignored in 8.0.0+; it was used for the ‘rollback’ feature in the legacy project system.
If you’ve got sufficient backups of your project(s) and gateway, you can simply drop the table directly. I would probably not do it while the gateway is running, and you can manually run the VACUUM pragma after to recover the emptied space.
I had a look and the table only had 1000 rows. I deleted and vacuumed, and it didn’t change by much at all, still at 224MB. The TAGSCONFIG table has 51k rows in the frontend gateway that doesn’t need to be there, but I assume just deleting the table data would be bad…
The answer appears to be ‘no’; deleting the provider itself doesn’t trigger a deletion of the associated records. It should still be safe to manually delete…but that’s probably something we should fix.
sqlt_* tables are the historian's recordings. They aren't part of a gateway backup. If you upgrade in place, your upgraded server will simply keep using the existing tables in the database. If you upgrade into a new environment, your history starts over.
History is not part of the upgrade process itself.