Deleting records doesn't normally remove the file block space allocated for them when the records were created.
To recover space, you should open the non-hosted file in FileMaker Pro Advanced and save it again, using menu File > Save a Copy As ...
and specify Type: compacted copy (smaller) in the file save dialog. This compacts the data so that less file block are used and removes empty blocks. It may take a while depending on file size and complexity.
Do you use a lot of non-native graphics on your layouts (jpg, png,...)?
Under the hood FM stores those in a library and in your case it looks like it got corrupted.
Thanks for your input. it works.
During the testing, I also found:
Size A( Save As compacted-> remove admin account)=Size B (just directly remove admin account).
"Remove admin account", it seems as well "doing compacting" process.
Previously I always wondering why "admin" took so much space........
in my solutionon, not really using a lot of jpg& png.
in this case, it seems "dummy block space" issue.
Thanks for inupts.
Recover has a clean-up step, that detects "stranded" ( no longer referenced ) library data, and creates a new table, with one container field
Libraries contain the items stored in container fields such as graphics, Word documents, or other FileMaker Pro files. There is also a library for the file that contains any graphics stored on the layouts ( and some that may no longer be in use )
> the size dropped to ~ 9MB after I deleted the recovered library table
If you're making a lot of container transactions and your container content is stored inside of your database, you're probably fragmenting blocks inside of your database similar to how hard drives become fragmented from thousands of read/write/modify actions with files (HDD defragmenting always regains some "space" back, I used to use an awesome program called Auslogics Disk Defrag when I worked in IT).
The "Save as Compacted Copy" is FileMaker's "defrag" operation, but it can only be performed on offline files. Depending on how often you anticipate the need to "compact", it might be better to save your container content outside of filemaker. You can avoid the fragmentation by storing container data externally, rather than in your file. This has become increasingly easy to do with later versions of FM. Maybe this is something for you to play around with in a test copy of the file.
yes, but that's not really the problem here
these are left over images, in the Library, that you can not otherwise delete
> it might be better to save your container content outside of filemaker