1 2 Previous Next 16 Replies Latest reply on Jun 22, 2017 6:54 AM by dtcgnet

    Managing containers


      I have a DB that is set to use managed containers [hosted location]/images/


      And several containers field that are linked to this storage location with secure storage.


      There are several thousand files in the image repository.


      What will happen to the image repository if i delete the container fields from the table?



        • 1. Re: Managing containers

          Any testing I've done of this indicates that if you have allowed FM to set up the container storage, and it looks like you have, then if you delete the field FM will delete the entire storage structure and its contents.

          Not sure why you are asking, but if your concern is losing the images themselves, then you should change the storage method first. In the process, FM will offer to convert the field contents, which you would accept. Once the images are released from FM's control you can set up a different storage directory for them and they will be unaffected if you then delete the container field.

          1 of 1 people found this helpful
          • 2. Re: Managing containers

            that is exactly my concern.

            I copied the file and hosted it on a server and i'm using the new file as the basis for a new solution.

            The container fields will not be used in the new solution and I want to delete as much garbage as I can.


            I don't think ill be able to change the containers back to internal storage as the server would not have enough space to let the file expand far enough to accommodate the images.


            And i can't experiment and risk losing valuable data/images.


            Suggestions on exactly how to get this monster ready for surgery?

            • 3. Re: Managing containers

              Hmm! Some thoughts:

              1.     It seems to me that if you change the storage settings for a container field it defaults to Internal storage.

              2.     It appears as if the process happens simultaneously—the container content is transferred and the external directory is deleted—so there may not be any effect on storage space.

              3.     You would then have to create the new directory, export field contents, then delete the container field, and thus its contents, so there could be a doubling happen here.

              4.     However, you could be able to minimise this with a script that deletes the field contents immediately after export, so you only double up one record at a time.


              That's the work path I'd experiment with, anyhow. Hope you can solve it.

              1 of 1 people found this helpful
              • 4. Re: Managing containers

                Thanks for the suggestions.

                Anyone in the community that has actually gone through this process who can provide me with a step by step process?

                • 5. Re: Managing containers
                  Magnus Fransson

                  Hi Kris,


                  For the creation of a new solution, you would have the server make a backup of the solution (and check the box to have the server make a "clone" of the backup) and then copy that cloned backup to your "worker computer".


                  That copy you can do what ever to, without any effect on your original file. You could even rename it (if more then one file, use the "renaming" part of the developer tool) and host it, on the same server.


                  With best regards Magnus Fransson.

                  • 6. Re: Managing containers

                    Thanks for the feedback Magnus.

                    I have already copied the fmp12 file and hosted it on my server so that is not the issue.

                    The issue is that I now have TWO files (old.fmp12 and new.fmp12 for arguments sake) pointing to the same secure external storage image repository and need to change the container storage in new.fmp12 to internal storage without causing any change in the image repository or container functionality in old.fmp12.

                    if I delete records or container fields in old.fmp12 it will destroy the integrity of the image repository.

                    if I change either fmp12 file to internal storage FileMaker will try to ingest the image repository and will choke when the operating system says it is has insufficient free space thereby damaging the image repository.

                    Guess i have two choices...thoroughly test possible solutions until i find a method that works perfectly or build a completely new new.fmp12 file.

                    • 7. Re: Managing containers
                      Magnus Fransson

                      Then make a clone and rename that. Then you will be safe.


                      Or actually, move the file to another folder. The external storage mechanism (if not tampered with) will expect the external storage folder to be a certain (fixed) subfolder to where the fmp-file is stored. So if they reside in different folders on the server they will use different subfolders to store the externally stored files. And thus will not interfere with each other.


                      With best regards Magnus Fransson.

                      1 of 1 people found this helpful
                      • 8. Re: Managing containers

                        There is this from FMI: "Note: Container data folders may only be referenced by one database at a time."


                        Your container data for "old.fmp12" will typically be in:

                        FileMaker Server/Data/Databases/RC_Data_FMS/old


                        Your data for "new.fmp12 would be in the same location, with "new" at the end.


                        Check those locations. If a folder for "new" exists and one for "old" exists, you shouldn't have the problem you're worried about.


                        How to move container fields with external storage between databases | FileMaker

                        1 of 1 people found this helpful
                        • 9. Re: Managing containers


                          In this instance things do not operate as you suggest.. at least on locally/not hosted files where i am starting my testing.

                          If I have file old.fmp12 that has one record and one container field with external storage and the container has image1.png in it...

                          The external storage location specified in the manage containers + container field definition will have one (secure stored or unsecure stored image) image.1.png in it.

                          If I copy old.fmp12, rename it new.fmp12 and open both files in separate FMP windows they connect to the same image1.png.

                          If I cut the image in the container, delete the record, table or container field in old.fmp12 image1.jpg is deleted from the repository and new.fmp12 is broken. old.fmp12 remains fully functional.

                          if I insert image2.jpg into the container in old.fmp12 image2.jpg replaces image1.png in the repository, old.fmp12 remains fully functional and new.fmp12 is broken.

                          If I change the container storage to internal in old.fmp12 i get prompted to transfer, transfer occurs, external storage of image1.png is deleted, and old.fmp12 remains functional while new.fmp12 is broken.


                          i suspect that this will behave the same whether hosted on server or not.

                          if that is the actual case none of these options will work because changes in one file will break the other.

                          • 10. Re: Managing containers

                            Clone wipes out the record and does not touch the image repository however the settings to the image repository remain and can not be altered without invoking a transfer.

                            Clone is not an option...

                            • 11. Re: Managing containers

                              I did this.


                              Create a database: TestContainer. One data table, one field: ContainerField1. I set that field to use external storage (open). I created a record and dragged an image into the field.


                              I then duplicated the database: TestContainer copy. As you note, it will continue using the same image repository. The container location can't be edited, because it is not empty.


                              Close both databases. Locate the folder where the images are stored. Create a new folder, OUTSIDE of that folder. Leave the parent folder, and move the contents to your new "ContainerImage TEMP" folder. Open TestContainer copy. Go to Manage Containers. Modify the path so that it uses "TestContainer copy". Close the database. Move the contents of TEMP back into their original folder.


                              Open the original database, and it'll be fine. Open the copy, and you'll note that the image is "missing" (since there are none yet). Then you can delete the container fields and nothing will happen to your original images or database.


                              Make copies.

                              • 12. Re: Managing containers

                                I got it..

                                Here are the steps that actually work.

                                1. copy old.fmp12 as new.fmp12

                                2. create a new, second, base directory via manage containers in new.fmp12. An actual directory/folder is not even needed on disk.

                                3. point the container in new.fmp12 to the new base directory in the container field definition.

                                4. when prompted by the transfer dialog deselect the container field in the transfer dialog and click Transfer.

                                5. Delete the original base directory in new.fmp12


                                When you do #5 you get this dialog stating....


                                Click yes and new.fmp12 is now filled with broken references to images because the base directory in use by the container field is empty.

                                Deleting the containers is now possible without affecting the original image repository.

                                This works with open or secure storage.


                                Thanks for helping me think this through!!!!

                                • 13. Re: Managing containers
                                  Magnus Fransson

                                  Hi Kris,


                                  As far as I know, FileMaker stores externally stored container data in a sub folder path that is:


                                  1. Relative to the storage of the fmp-file. (Meaning that if two files, with the same name, are stored in different folders they should never store container data in the same folder.)


                                  2. Uses both filename, table name and fieldname on different sub-folders before it reaches the finale sub-folder. (Meaning that if more then one fmp-file (with different names) resides in the same folder or a database contains more than one table with container-fields or one table contains more then one container-field, they still would not touch each other’s data.)


                                  Thus the only way you could have reached the situation you claim to be in, is if you have manually altered the path in which the external container data is stored. Then create a clone and manually alter the path for the clone to store its container data in another place.


                                  With best regards Magnus Fransson.


                                  Skärmavbild 2017-06-20 kl. 17.49.24.png

                                  • 14. Re: Managing containers



                                    In Manage Containers, you'll note the location auto-set by FileMaker. When an image is inserted, the necessary folders are created by FM. Once anything is inside of that folder, then you can't edit the location.


                                    So basically, with the databases closed, just move everything out of that location into some temporary location. Once that location is empty, then you can open your "new" database and edit the external storage location for your NEW database. Then close the new database. Then move everything back into the original folder.


                                    Your "old" database will not have been affected at all. Your "new" database will now reference a different location, and you won't have to worry.


                                    I'd be careful trying it with Secure storage, but with Open storage...no problem.

                                    1 2 Previous Next