Are these images with duplicate names linked to the same parent record?
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.
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?
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.
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.
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.
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.
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.
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.
Thanks, Carsten. I usually set things up as Wim describes (separate folders), or via secure storage, so I wasn't sure.
If you want to see the example file and the attached fields.
Where is the example file you mention?