How does one reduce the size of a BaseCamp database...
You can't unless you delete data in your collection :)
There's really not much dead space in the BC "database"--that is the files that make it up. One can back it up and compress it (e.g. BC backups are in the ZIP format) but it can't be used until decompressed again.
As I said, this is a trick question. Since you fell for it (although not a Dev Team member) I'll share my frustration.
You can delete data in your My Collection until there is nothing left and when you close BaseCamp the database will still be at the size you started with. Give it a try (make a copy of your DB of course).
The only way to get the DB to shrink to the actual size of the data once modified, is to create a Backup. Which, as you noted, does compress the DB and, more importantly, removes the "white space".
I don't own a Mac and don't use Mac BaseCamp. That said I'm pretty sure the database is the same, or very similar, between the Mac and PC versions.
On the PC version there is no "white space" to get rid of as I indicated. The database consists of many files and those are deleted or modified as you add/remove data. On PC's the database (files/folders) fluctuate in size as you add/remove stuff.
I don't know what filesystem Mac's use these days. It could be that files/folders aren't really deleted immediately making it appear as though the database isn't getting smaller.
There's a reason this is posted on the MAC-BaseCamp forum and not the WIN-BaseCamp forum... ;)
The Mac file system is one of the best in the world. Garmin is using the "library" feature to manage all of the BaseCamp files (mydatabase.bclibrary) which makes it very easy to remote databases and start BaseCamp by simply clicking on the DB library. They just forgot to do housekeeping so that deleted data space (which I loosely called "whitespace") is removed when the DB library is saved.
I think your observations is very common in legacy data bases and unless the database is storing data in a blob, it still pretty common. The house keeping you refer to was usually in the form of a compression procedure or app that removed the space uses for deleted records. I have not tried it but I would think that your empty DB showing original size will not get larger as you add records until you reach the original size. I bet BC will use space left by deleted records before allotting new space . As for the trick question just create a new DB. The results might not be acceptable but if you create a new database and import your smaller collection is another way to decrease your DB size.
Are you suggesting that this is OK? That ignoring the bloated Library of an empty DB collection is acceptable? Aside from my personal expectations, this is an easy fix for the BC Team and I would like to see it dealt with--it is a rather significant inconvenience for the people I share my DB's with.
No, I'm not suggesting it ok and I am just guessing as to the database structure but I'm think the fix as you suggest would involve much overhead and slow BC noticeable. I am thinking the only practical fix is a procedure that users could run to compress the database. Unless the developers are using blob storage, I think to remove the extra space from the database means you have to completely rewrite the complete data set.
I don't agree. Proper coding and this will not be an issue (obviously isn't for most 'cause they don't share databases with a remote team). Never the less, I believe this to be an easy fix and in operation would have absolutely no impact on BaseCamp performance--it's a file closure process.
As I said earlier I'm guessing; the small size of BC database might make it practical. The major databases I have used in the past had compression run as a procedure and it took several minutes even for small databases. The file management on all operating systems allot storage in large blocks like 512K. These blocks continue to get larger as more storage space is added and OS file management is update. I'm guessing BC is using legacy storage were the amount of space for each field in a record is allotted in advance. To reclaim space in these systems is like defragging a hard drive. As you have noted Mac never had the defragging disk problem and the mac may have a call to reclaim space in files. Maybe the developers is let us know if that is the case.
I think you missed the point of the "Mac Library" part of my reply. I'm using the term database loosely here. The real issue is the Library. The actual database (AllData.gdb) is being reduced as data is removed. The Library "container" however is not.
