Inserting them all into containers would probably cripple the database and make it huge.
That's why there are two options for working with files in container fields in FileMaker 12 that you can use:
- Specify External Storage for the container field. Files are then stored externally on a folder on the host machine as specified by you when you set up this option. (Do NOT use "store a reference" when inserting/importing images into this field.)
Use "store a reference" as an option for inserting the file (only option you can use for this in earlier versions). This stores the file path to the file inserted so your file size does not increase by the size of the inserted file. In a networked database, it sometimes requires a bit of scripting so that the user inserts a file and then the script exports it to a shared directory on the host machine and re-inserts it by reference from that location.
The key detail here is that each client machine must map/mount the shared folder in exactly the same way so that the file path in the container field is a valid file path from the context of that user's machine. Since Mac and WIndows systems need different file paths to that shared folder, this gets complicated if you have users with both systems on the same network and is a key reason why FileMaker 12 added the external storage option.
Okay - they're all macs so I won't have to worry about that. Say I wanted a file path for external storage that navigated to a dropbox folder relative to whichever computer it was on? So regardless if it was Mac 1, Mac 2 or Mac 3 it would always know to go to 'xxx/Dropbox/xxx'
Is this possible?
It's possible, but seems a needlessly complex method to use given the alternatives available.
You can define a calculation field to compute the file path to the file in the form found inside a container field then select "Container" as the result type for the calculation. The calculation can extract the file path from the container field into which it was inserted "by reference" and then modify that file path in order to produce a file path that is valid for the current computer.
Note that this requires using a container field to insert/import the file and a separate calculation field with a container result type to display it on all client computers.
You may find this thread and it's downloadable exploration file to be of interest: Exploring the use of a $Path Variable in Scripts
Okay thanks for the tutorial file - I think I'm sort of getting it - do I need to replicate those fields & scripts on my database to allow it to extract and edit each file path? I think the only part I don't understand is how to tell it to modify the link it finds. Is this the 'Filepath with Get Functions'?
This method seems quite complicated, I'm guessing it's a lot simpler with filemaker server handling all of the files?
The demo file is set up for one purpose only, to help developers learn how paths, path variables and paths stored in container fields work.
It's a lot simpler if you use External storage. Or store by reference to a shared directory. That's what I've been trying to tell you.
Ah okay great. In that case all I want to do is turn the dropbox folder into a shared directory between all of the macs and have it follow the reference there, but when I try this the path is computer specific.
I've even got the trial of FM Server to see if that can help, but it still doesn't seem clear where to put external files. I'm probably being stupid and it's fairly straightforward? All of the files I want in the database are organised in dropbox folders, I don't want to mess about with the external storage setting because this will mean re ordering them all. I just want filemaker to point to the shared dropbox folder on the network and know where to go regardless of the mac.
Don't use drop box. Put a shared directory on the same computer that is hosting the database. The client machines will need to map/mount this shared directory. This assumes that all computers are clients of the same network.
Even simpler: don't use a shared directory, use the external storage field option and this should make the files available even for users outside the network.
Yes, the external storage option means I can see the files across the network. But this still doesn't treat them as references. I want to be able to double click on word documents and have them open in word and be edited. Is this possible?
It's always the detail not previously posted that trips up a suggested solution...
Option 1: Use the shared directory. This requires that you go to the directory on the server and change its properties in order to have it accessible for read and write access over your network. If this were a windows server, I could be more specific. Then set up a system script that mounts the shared directory for the user. You can set up fileMaker to perform this script for the user to ensure that the folder is correctly mounted and in a manner that results in the correct file math matching what is stored in your container fields.
Option 2: use external storage, but add a button to open the file in place of the double click to open the file. You may choose to have the container field itself to be that button and then clicking the container field will open a copy of the file. The script performed by this mouse click would use Export Field Contents to export a copy of the file to the user's temporary folder. You'd then add a save button on your layout that inserts the copy from the temporary folder back into the container field to "save" the changes made by the user.
The options have a trade off:
Option 1 requires careful management of how the user mounts the shared directory in order for them to have access to the files to see and edit them, but you can double click to open the file and when the user saves, the changes are saved back to the original location. This also gives your users unrestricted access to the folder a user could, by accident or design, delete all the files from the shared directory--a considerable security risk you may not want to run.
Option 2 avoids that extra complication for managing access to the shared directory, but now users have to save their changes twice--once from the application that opened the file and once from FileMaker to copy the modified file back into the container field. (You might, however find a way to use navigation buttons or a script trigger to automatically re-insert the file so that the users don't have to remember to click a save button.)
Option 2 sounds like the one for me - Is the scripting to export field contents to a mac's temp folder straightforward? I don't think saving twice will be too much of an issue given the convenience of being able to open & edit.
Thanks as always!
Is the scripting to export field contents to a mac's temp folder straightforward?
You can compute the path and put it in a $path variable. There's a get function that returns the path to the temp folder. See the exploration file that you have already looked at for examples of this.