In FM12 there is not difference where the file is store between dragged & dropped and inserted into container. By default the file is store in the container field. You can store your file externally which is relative to the database.
When you drag and drop into a FileMaker container field, you are doing exactly what Insert Picture, with the "Store a reference" option not selected does.
This action embeds a physical copy of the file into the container field. Thus, there is no file path that you can capture from that drag and drop process.
If, on the other hand, you use one of the insert menu options and select the "store a reference" option, the file path is stored in the container field and can be extracted from that file if such information is needed.
That's unfortunate. This s for a document tracking/indexing solution. Ideally, the user
1. D &Ds a scanned document / file into FM
2. calculation(s)/script(s) determine the file path
3. that information is used in a calculation (container) field from which the document / file can be opened
4. the document / file is opened by the user and key ID information (i.e. name, date) is entered into appropriate fields
5. an AppleScript is used to rename the file using the new ID information
6. the file path and new name are used in a calculation (container) field to either directly store, or store a reference that can then be opened from within FM database.
This can be done if the document / file(s) are named and located strictly; in other words, there is a strict naming and location convention. But its a stretch to expect that of all end users, so I have to be able to automatically obtain the complete file path. An alternative is to initially "Insert" the document / file, but that is more time consuming than simply D &D.
Ideas are appreciated. Perhaps there is a way to automatically (or by default) set container fields so they "store a reference" even when used for D & D?
Try it this way:
With the file dragged and dropped, Export Field Contents can be used to open the file by exporting it to a designated location such as the Temporary Items folder and opening it. This is both a menu option and a script step.
If so desired, this step can also be used to export the file to a designated folder for storage and then the file can, via script be re-inserted into the container field with the "store a reference" option enabled. This process, can also rename the file--eliminating the need for AppleScript.
If you are using FileMaker 12, you might also experiment with specifying external storage for the container field. With that option, any file dragged and dropped is automatically copied to a designated folder for external storage. That simplifies everything but renaming the file,
Technically the file name stream (FNAM) in a stored container does store the original path, but it cannot be read without a plug-in, because GetAsText() only returns the file name itself.
I cannot get container images to view on both platforms (mac/pc) so I thought of trying to use the path iinformation to redirect according to platform but cannot get full path to display using drag and drop as mentioned above (I have 100s of images to insert).
I should add that I have set up the paths/locations within File > Manage > Containers > Base Directories (with thumbnail temporary storage selected) for both platforms.
Do I need to also setup open storage option within the container field options or leave that unselected?
Phil, I don t understand how to creat the script to reoslve this from your suggestion "and then the file can, via script be re-inserted into the container field with the "store a reference" option enabled."
I cannot find script option to import from folder.
Could you show a sample script please.
I have now found the import folder option in scripts - it is only available under View > all by category > Records, not listed under view > all by name!
... another FMPro12 bug?!
1 of 1 people found this helpful
- Technically the file name stream (FNAM) in a stored container does store the original path, but it cannot be read without a plug-in, because GetAsText() only returns the file name itself.
I know it has been a while since this thread... do you have any idea of any existing plug-ins that are able to read this FNAM original path information? Or any changes within subsequent FM versions that have enable this, for locally stored container fields?
We have a work around that scans a known path structure for the filename, but this is NOT exact and can been fooled by multiple similar named files.
Thanks in advance for any advice you can give.
To the OP (ecologist):
I don't have an answer for your specific question but this might be food for thought.
I've been puzzling with this one as well. I'm not a fan of container fields because often a user might access a file in different ways from within the database and also might access a file from outside the database. Here's what I mean:
Accessed from different places from within FMP: A user is working on a project and makes notes, and mentions a PDF working paper in the notes. It's easy to drag and drop that pdf working paper into a FMP container field attached to that note. However, if there are several people making notes over a period of weeks with references to that same working paper, then the working paper file is unnecessarily getting stored multiple times. If that working paper gets updated then there is a version control problem (files that are different but with identical names can be put into a container field). It's possible to put the container field into a separate table and have a many-to-many relationship between Notes and LinkedFiles using a join table. But that gets complicated quickly (e.g., how does the user find the file in the LinkedFiles table? E.g., what if users like the nested folders of OSX Finder or Windows?)
Accessed outside of FMP: unless a company has a full-featured document management system that is used by everyone, all the time, perfectly, users will inevitably put files in the native Windows or Apple file folder structure on the server (or in Dropbox, etc). We can insert that relative file path into FMP, but as soon as some user changes a filename or reorganizes the files into sub folders, the file path reference will break.
As a result, I have been experimenting with dropping a OSX-generated UUID into the file. Then a FMP record for a note (using my example) can contain a field that holds this UUID. A script then can direct Finder to locate it in an instant. Oddly, I've learned that neither MSFT nor Apple generate UUIDs for files natively (good grief, why not?). Another small problem is where to store the UUID as neither MSFT nor Apple have a metadata field for it (again, good grief, there is a metadata field for the f-stop for photos but not for a document id?). Most doc management systems put them in the document footer or at the end of the file.
I'd like to learn more about document management systems on Filemaker, but there seems to be little written about them and I have yet to see any example files that would survive real-world use and abuse.
2 of 2 people found this helpful
I can write this very quickly. I have a plug-in (not yet released, but working), it's extensible, and this will be a simple thing to add. Send me a private message if you're interested.
1 of 1 people found this helpful
Update: this was indeed an old thread. FileMaker has changed the format of container fields in v12 and the 'FNAM' stream no longer stores the full path information, only the file name. This means that if the file is stored in FileMaker, the original path is lost forever and cannot be recovered. Only the file name remains.