Thank you very much. On a related note, curious if you gentlemen have any comments relating to the worthiness of performing a "Manual" upgrade (as described above) over an auto upgrade + just dropping tables that are empty in a "Manual" upgrade. Does the export/import process have more robust error checking/conversion routines than the auto upgrade process? (Do we potentially gain anything over the auto upgrade alone?)
At the moment, I don't think the 'manual' upgrade process you're describing is actually getting you much.
We're not deleting any 'legacy' tables, so your .idb will still be inflated with these (since you ran the restore process).
You could get around that two ways:
- Export your tags and projects from the 7.9 gateway.
- Remove your tags and projects from the 7.9 gateway.
- Take a new .gwbk.
- Restore the .gwbk onto the 8.X system.
- Manually import the tags and projects
OR
- Restore the (unmodified) 7.9 gwbk onto 8.X.
- Manually drop the offending tables from the 8.X config.idb.
I would consider the second option 'safer' in terms of upgrade behavior (I don't know the current state, but at least in the past there have been issues where the upgrade does different things to tags than an import does) and it's a whole lot easier. If you're not comfortable with which tables to delete or the process of deleting them, I'm sure our support department could help you.
I will also mention that it's entirely possible that it's just not necessary. We only start seeing issues, generally speaking, with very large systems, as in systems where the config.idb is hundreds of megabytes or more. That mostly happens because of inefficiently stored binary data; e.g. someone has chosen to serialize very large datasets in Vision or many, many image files into Image Management. If you're not actually having a problem after upgrade, it's probably totally fine to just upgrade and restore the .gwbk. In some future version we'll truncate those tables for you automatically, and as a nice side benefit your .gwbk will get lighter.
1 Like
Thanks again for the insight. May reach out to support to confirm re proper idb tables, but I think I have a pretty good grasp with sqldiff, sqlite_analyzer, and manual comparison.
For reference, we're seeing config.idb sizes between 700MB - over 1GB after auto upgrade (in test environment), and though it's probably fine, we thought to investigate the cause.
History is all properly stored in SQL elsewhere.
1 Like
I would definitely take extra steps to clean up when dealing with sqlite sizes that big - so I think you're heading down the right road.
1 Like
Holy moly 
out of interest, how big is the project? (tags/Windows/Templates?)
While I'd be happy to answer here if it was just my project, not sure I should in this case. We're in the process of slimming it down/splitting it up.