I haven't seen any other reports like this. I suspect that this "bloat" was a result of damage to the file that could not be detected/repaired until you added that record to the table, not something that will happen everytime you set up a global container field.
Wonder what you'd get if you tried saving a "compacted" copy of your original, unrecovered file?
Yep, first thing I tried was saving as compacted, but didn't compact anything much at all.... Saving as clone did as expected and resulted in empty file...
And what did you get if you then imported all your data from the recovered copy into the clone? You generally do not want to put a recovered copy of a file into regular use unless you have no better alternative.
That works just fine... and is what I will do to replace the live file... However, I am in the UK and the system runs in the USA, so will wait until the morning my time when it is not in use to do the changeover...
I think I will also make sure that the 'utility' table does actually have a single record in it as well as tightening up on the deletion of the container field content, e.g. actually deleting the contents and commiting before replacing with new PDF file... May help I guess...
thanks for your suggestions...
The nasty reality that we have to face here is that we do not know why this happened in the first place and your clone may or may not contain hidden damage that could cause this to happen again. You'll have to keep an eye on the file size and see. Be prepared to replace the entire table or even the entire file from scratch if you can't find any other way to prevent a recurrence.
A couple things that occur to me
1) there is no records, solution use just one record
2) Save as global. A hosted file isn't suppose to save the global other than what is stored in it when not hosted. Solution: The field dosent need to be global since there is just one record in it. Make a connection to that table with an "x" join, and any table with that join will find the record (as there is only 1)
As far as my solution is concerned it shouldn't matter if there are no records, 1 record or 100 records... It is just a global container field used for temporary storage, and the system is accessed by around 5-8 simultaneous FileMaker Go on iPad connections, any one of which may use that global field to insert a PDF at any time, so making it non-global wouldn't really work here..., though I am considering changing the system so that each client FileMaker Go connection does actually save the PDFs to their own unique record, even if temporarily.....
I see what you are saying, so the global is only for that session, so if they lose connection the data is lost. Perhaps a table with one record and each person has a container field in that record.....
Clearly your results show the file is growing which indicates the PDF is saved after the session ends. This I suspect is because the field is global and perhaps it saves it in a temp place with a dropped connection, a FM mystery. But at the end of the day why it is happening is more than likely tied in to the fact that it is a global and it is on a table with zero records.
Though a pain, this is normal, and no real way to prevent it. I have seen it a few times
Fortunately, Since FileMaker 8.5, Recover now cleans up these orphan items in the library
In the past, you had to make a Clone
FileMaker's Clay Maeckel explained that the appearance of this "Recovered Library" or "Recovered Blob", by itself, is not an indication of corruption, since Library data can get "stranded", even in a "healthy" file, and is now cleaned up
However, if it is repeatable in your Solution, please report it as a bug.
It is also odd that Recover did not see the bloat, the first time around
> Is there any way to prevent this bloat build up of 'old' container data ?