13 Replies Latest reply on Jan 8, 2016 2:24 PM by jetalmage

    Container External Storage Overwrite

    jetalmage

      In a parts catalog solution, it is not unusual for the same exploded illustration to be used on multiple page records. After changing the container fields involved to take advantage of external storage (open), FileMaker now automatically appends serial numbers  ("_1", etc.) to the file names where they are stored, rather than overwriting the existing file of the same name.

       

      Searching for an answer to this, I ran across articles on using External Storage, on web sites of two different FileMaker developers. One says:

       

      "If you insert two files of the same name, the previously stored file will be overwritten."

       

      Another says:

       

      "If you import two files with the same file name then Filemaker will automatically add serial numbers to it to avoid overwriting matching files."

       

      How can I control this behavior? I need FileMaker to not auto-append the serial number to the externally stored images, but instead overwrite any existing file of the same name (just as FileMaker does when I export PDFs, for example).

       

      JET

        • 1. Re: Container External Storage Overwrite
          Mike_Mitchell

          Are these images with duplicate names linked to the same parent record?

          • 2. Re: Container External Storage Overwrite
            jetalmage

            Hi, Mike. Thanks for the reply.

             

            Each Record in the main table is essentially a list of related parts. For the sake of discussion, call these records Pages.

            Often, the same exploded parts illustration (in both a vector-based PDF and a raster PNG format) is used on multiple Pages.

             

            With the Container Field set to use External Storage, drawing 12345678.pdf is inserted onto Page record 10. FileMaker writes a copy of drawing 12345678.pdf in the directory designated for External Storage.

             

            Drawing 12345678.pdf is then inserted onto Page record 11. FileMaker writes another copy of the file in the designated directory and auto-names it 12345678_1.pdf instead of overwriting the file already there.

             

            I'm talking thousands of drawings here. Before using External Storage, if I Exported the Container fields to a directory, pre-existing files of the same name were overwritten, thereby resulting in only one copy of each illustration. This is also what occurs when exporting PDFs (of the whole Layout).

             

            That's what I need External Storage to do: overwrite same-named files instead of auto-appending the serial suffix, and thereby creating multiple copies of the same illustration with different names. Otherwise, External Storage is of no use to me for the catalog.

             

            JET

            • 3. Re: Container External Storage Overwrite
              wimdecorte

              Typically the path for the RC data is calculated to include the table and primary key as folder names so that you won't have that issue.  Does that work for you?

               

              Best regards,

              Wim

              • 4. Re: Container External Storage Overwrite
                Mike_Mitchell

                If one document is associated with multiple records, then I suggest you modify your data model. Create a table of documents (if you don't already have on) and a separate join table that contains the keys from the Pages and Documents. When you want to connect a document to a page, create a record in the join table. That way, you only have one copy of the document referenced in the database, and your overwrite problem goes away.

                 

                HTH

                 

                Mike

                • 5. Re: Container External Storage Overwrite
                  jetalmage

                  This solution pre-existed the External Storage feature. Rather than change the schema, we'd just go back to Store a Reference Only and maintaining the directories of illustration files on the server.

                   

                  I'm not the only one having encountered this problem. It seems quite sensible to have a database which uses the same images on multiple records. There should be an option controlling whether External Storage overwrites existing files.

                   

                  Suppose, for example, someone just wants to drag & drop an updated contact's photo into the existing record.

                   

                  JET

                  • 6. Re: Container External Storage Overwrite
                    jetalmage

                    It also seems odd that FileMaker Help does not mention this behavior (not that I have found), since it differs from the way Exporting works.

                     

                    JET

                    • 7. Re: Container External Storage Overwrite
                      Mike_Mitchell

                      I believe (Wim, correct me if I'm wrong) that the external pointers to the managed assets are based on the record, not the document. IOW, if you have "the same" document stored on two different records, the managed container feature needs to maintain pointers back to both records - which it likely can't do. I have a solution in production where I witnessed the same phenomenon as you, and it was because of people inserting documents with the same name on multiple records. (As an aside, if you put the same document on two different records via embedding, it will be in the database twice. Same principle.)

                       

                      FileMaker has no idea that the two objects on two different records are, in fact, the same and should be treated as one overwriting the other. (From a data integrity standpoint, that would be Bad.)

                       

                      All that aside, it's extremely inefficient to store the same asset more than once. It's costly in terms of backup storage, backup time, performance, etc. It also violates basic normalization principles.

                       

                      As for your example - dropping an updated photo onto a record - it WILL be overwritten, because it's on the same record. (I can verify that from personal experience.) It's just when you put it on two different records that it represents two different objects.

                       

                      You can do as you see fit. But regardless of how you got into the situation you're in, I would suggest to you that the schema need to be altered to something more properly normalized. Your other alternative would be to switch to secure storage. That will eliminate the file name conflict. Since nobody should be touching the assets directly through the OS anyway, not being able to access the file via that route is largely irrelevant.

                       

                      FWIW

                       

                      Mike

                      • 8. Re: Container External Storage Overwrite
                        keywords

                        Re: "It seems quite sensible to have a database which uses the same images on multiple records. There should be an option controlling whether External Storage overwrites existing files."

                         

                        First, I totally agree with what Mike has said. If you want "the same images on multiple records" you need to handle this as suggested by Mike. FM can't be expected to second guess you. Suppose you had a pic of yourself with the name JET.jpg stored in one field or record, and another pic called JET.jpg in another field/record—except that this one is an aeroplane. Imagine what would happen if FM assumed that the two are the same image because they have the same name. Equally, if you had two identical images but with different names FM could not tell that the content of the images is identical, even though the names are different.

                         

                        It is the database designer who has to make decisions based on use case. And it sounds as if you have a situation that calls for a separate table for storing images, and a join table to connect to them.

                        • 9. Re: Container External Storage Overwrite
                          CarstenLevin

                          Here is the authoritative explanation:

                          • If you add the same file to more records it will only be stored once. See the first 3 records in the example. 3 Records, just one file in the file folder.
                          • If you ad another file/picture with exactly the same name, but with just the slightest difference it will get an added version number.
                          • If you ad a file/graphic and then open it and change just the slightest detail it will be void and show "Tampered" in FileMaker.

                           

                          It is very economic that FileMaker does like this. But I would consider having a table for the files/pictures and then a join table/many to many relation to pair documents to your master records.

                           

                          I hope this settle it.

                           

                          Best regards

                           

                          Carsten

                           

                          dump.png

                          • 10. Re: Container External Storage Overwrite
                            CarstenLevin

                            If you want to see the example file and the attached fields.

                            • 12. Re: Container External Storage Overwrite
                              Mike_Mitchell

                              Thanks, Carsten. I usually set things up as Wim describes (separate folders), or via secure storage, so I wasn't sure.

                              • 13. Re: Container External Storage Overwrite
                                jetalmage

                                If you want to see the example file and the attached fields.

                                Carsten,

                                Where is the example file you mention?

                                 

                                Thanks,

                                JET