5 Replies Latest reply on Nov 4, 2016 2:49 PM by TSGal

    Container storage - Open and external naming problem


      Current systems:

      FMS on a Mac OS 10.11.6 with a valid GoDaddy certificate of acceptable format to FMS.

      FMP on macOS 10.12.1 clients bound to Open Directory on a Server running macOS 10.12 and Server 5.2


      I was testing external storage for containers because a Documents.fmp12 store file is getting inconveniently large to back up. The backup is inconvenient in that, in order to back up the newest document added to the Documents.fmp12 file I must make a back up of the entire file which is now over 40GB.


      My plan was to push all saved documents to open storage which would leave a fairly small Documents.fmp12 file. The file now backs up easily and I can run TimeMachine on the documents open storage which will back up only the newest documents added since the last backup. I kept the open storage because it would be on a server and not accessible by general users AND most importantly I could get back into the files manually to find documents if needed as long as my naming scheme permitted doing so. The idea was to set this up as a fall back against corrupted database files where the document linkages have been lost.


      In trying to set this up. I found an odd behavior that does not make sense to me. I set up a Test database with three fields and one record:





      The container field was set to open with the associated records being stored in a folder called: Name & Date


      The odd behavior comes in when changing either of the field names that the folder name is based on. If the document storage location is based on the two fields, and one changed, I would expect the name of the document storage location to change to reflect the new values.


      They don't.


      If I put in Name::Tom Date::10-31-2016 and add a document, and realize that I meant to put in Date::10-31-2015. If I make the date change, the folder name does not change. But the database does still show the document in the now mis-named folder. The now mis-named folder is also potentially very difficult to find again under my plan because it would not be under the proper date.


      Additionally, if I make the date change and then remove the attached document, and add a replacement document back in, it shows up in another folder under the new and correct date. The old mis-entered folder still exists in the filesystem. So depending upon how I set this up it seems that I could have huge numbers of empty folders around.


      This gets more complicated if the documents are placed into a related table linked by a serial number but the naming scheme is the same. Let's say I am saving some documents in my record for Tom.


      Let's say I have Name::tom Date::1-1-2014 and I put in a document. The attached document is saved in /tom1-1-2014

      Let's say I changed to Date::1-1-2015 and added a new document which is saved in /tom1-1-2015

      Let's say another user changes to Date::1-1-2016 and added a new document which is saved in /tom1-1-2016


      For a single database record: I now have 3 differently named folders, all containing 1 document each, rather than the expected 1 folder, renamed with each data change, with 3 separate documents.


      The database can still see all three of the documents but my effort to consolidate my documents just broke down and I cannot find them  manually because the three documents for tom are scattered all over the open storage folder, under names that I will not be able to reproduce because I cannot possibly know all of the errors typed into the records by the users over time.


      In general database use, a change in a field results in changes in related tables, calculations, etc. Why not with documents in Open storage?




      -Erich Wetzel

        • 1. Re: Container storage - Open and external naming problem



          Thank you for your post.


          When a Container storage is based on calculation of a field(s), the folder destination will not automatically change when the field value of that calculation changes.  However, if after you change the field value and insert a new image into the same Container field, then everything will be updated correctly.  That is, the old calculation folder will be removed along with the old image, and the new calculation folder will be created containing the new image.  If you have multiple Container fields in the table, then go back into the open storage calculation for each Container field, click OK, and when you finally exit Manage Database, a message appears stating the Storage options for one or more containers has changed with the option to transfer.


          In your case, I am unable to replicate the three differently named folders for the single database record.  Using your example, each time I change the Date field and replace the image, the old folder is removed and the new folder is created with the new image.  Let me know the steps you take so I can replicate the issue.



          FileMaker, Inc.

          • 2. Re: Container storage - Open and external naming problem



            Sorry I was not clear enough. The three container items in three places worked as follows. Sorry if I don't have my contextual terminology correct. Let me know if any of this is not clear.








            Container (open storage in the folder the database is in) - Name of storage folder = Table1::Name & Table2::Date

            Serialnumber::1 (for each added document)


            - Tables linked by Table1::Serialnumber = Table2::Serialnumber

            - Create records in Table2 enabled

            - Portal on Table1 showing several lines of Table2::Serialnumber





            Name = Tom

            Date = 1-1-2013

            Add document in portal showing Table2::Container, document is visible in portal

            - Document winds up in /Tom1-1-2013



            Name = Tom

            Change Table1::date to 1-1-2014

            Add document in portal showing Table2::Container, document is visible in portal

            - Document winds up in /Tom1-1-2014



            Name = Tom

            Change Table1::date to 1-1-2015

            Add document in portal showing Table2::Container, document is visible in portal

            - Document winds up in /Tom1-1-2015



            All three documents are attached to a single related record, are stored in three separate folders with three different names, and are all visible in the portal from Table1.


            Expected result:

            I would expect the 3 documents to appear in 1 folder named /Tom1-1-2015 because all 3 documents are connected to a single record and the value of the date in the folder name scheme changed with each change of the date value. This result matching how "data" and other details change elsewhere in the database due to a field value being adjusted.


            Let me know if you have any questions.



            • 3. Re: Container storage - Open and external naming problem



              The Result you are seeing is correct.  If you change one of the key fields at the time of the creation, then the image will be placed in the appropriate folder.  The older folder names will not change on their own.  Again, in order to consolidate the images, go back into Manage Database, select the Container field, modify the options, click on Specify to display the calculation, click OK to save the changes, and when you exit Manage Database, you will get the transfer message.


              If you are going to continually change a field referenced as a folder name calculation, consider hiding the Container field until the relevant fields are entered.  In your case, Table1::Name and Table1::Date.



              FileMaker, Inc.

              • 4. Re: Container storage - Open and external naming problem



                I understand. I was hoping that the OS folders could be changed by FileMaker on the fly and that those names would adjust the same way other data in the database does.


                The system is only able to edit the OS folder name once, on creation, for linking related documents. Once in place the folders can only be renamed by rebuilding the connections which is not a good thing to do regularly.


                In our case, in the event of comprehensive database failure, there are two dates and a name (all of which might be changed several times in general usage before becoming essentially permanent) that would help us find attached documents in folders with the names and dates if we could use them. If they changed on the fly.


                As an example, let's say that we have a person Tom J. Smith who was born 1-1-1939 and died 12-31-2015. You would assume that a name and those dates are static. But if I need them all exactly right before adding documents it is a problem. Suddenly, if I change the year of birth because someone gave it to us incorrectly, I have files everywhere like in the examples above. But if the OS folders can change with the database content, like calculations do, then our problem is solved.


                Feature request?


                Thanks for clarifying for me.



                • 5. Re: Container storage - Open and external naming problem



                  I understand what you are trying to accomplish.  This would definitely be a feature request, so please post this to the Product Ideas board at:    Product Ideas


                  The Product Ideas board is monitored by Product Management and Development.  All suggestions are read, discussed and considered for possible implementation in a future release.



                  FileMaker, Inc.