Is there any chance that the file was inserted with the "store a reference" option enabled?
Thank you for that thought. 90% of the container data had been living internally, until a few weeks ago, when I switched storage to external and moved it all. The remaining 10% was either brought in through drag and dropping onto the container field, or through an insert file script step set to insert, not reference.
or through an insert file script step set to insert, not reference.
Just a note that the same script step can insert a copy of the file or a reference depending on the options specified in the script step.
I think my script step was inserting rather than referencing (see photo) but you've got me thinking about the handful of files that I dragged and dropped into the container field.
The container storage in the manage database field setup was set to be external, and I deleted the files off my desktop after they were dragged into the container field successfully (which would have made them appear as broken links if I understand correctly) but I wonder if dragging and dropping into a container field somehow has messed up the save as self-contained option.
drag and drop is just a convenient method of inserting a copy of the file--the same options shown in your script step and thus should not be an issue here.
What storage options did you select for your external storage? Does anyone have access to that folder?
If it's not secure storage, have you checked that folder for one of these missing files to see if it's there?
The external container is open (not secure) relative to the location of the file. I am the only person with access and everything is there.
The self-contained copies that I am testing will show active links to the external container data when stored in the same folder as the original, but not when moved elsewhere, like the desktop for example.
Perhaps I am missing the whole point of a self-contained copy. It was my understanding that any externally stored container data would be brought back into the single, exported, new file, with external storage settings reset to internal. As it is working I do not understand the difference between what I have created and a simple copy of the file.
One additional note... there is a "Transferring container field data..." progress bar that moves slowly, and promisingly, at first. (I have about 1.8 GB in external data) But after about 30 seconds of going slowly to about 1/3 of the way, it speeds up as though it has given up, and completes in about 10 seconds. Is 1.8 GB larger than some limit on internal storage?
Here is a screenshot of the progress bar:
3 of 3 people found this helpful
By any chance are you using: File; File Options; Log in Using: Guest Account ?
If so, this seems to prevent “Self-Contained Copy” from embedding eternal-container data. It is an old problem going back many FM generations. Has been reported (by me) several times, every time a new software upgrade has been released. No resolution so far !!
Thank you Rouelf, yes, my problem is exactly related to this although some of the details were a little different. I found that I had to not only bypass the automatic guest login that I had set up, but to try other things too to make it a clean login. Opening my file with the option key held down to login with full access did not work. But I then deleted all my keychain login passwords, turned off the ability to save passwords in keychain, and then it was able to truly save a self-contained file.
What needs to change at FileMaker so that these kinds of problems actually get fixed? Or to ask another way, what is the most effective role I can play as a user to put pressure on FileMaker to realize these kinds of problems are huge turn-offs to product loyalty?
I appreciate your help Rouelf.