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…
I’ve deleted both the PROJECT_CHANGES and PROJECT_RESOURCES tables and all seems to be up and running and my config.idb is now 59MB down from 223MB
Does deleting a tag provider also delete the tags associated with it? I’m still a bit miffed why the tagsconfig is so big considering I deleted the tag providers and added remote tag providers
For the frontend, I deleted all TAGCONFIG rows where the PROVIDERID = 0 which provider doesn’t exist and used to be the old ‘default’ provider. Now it’s dropped from 59MB to 18MB, much better!
Now to check if it broke anything… doesn’t look like it
Now I’m really interested in the answer to this question
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.
Maybe images?
and my config.idb is now 59MB down from 223MB