There are plugins for file manipulation. Some are specific for graphic file manipulation.
Super Container was the most commonly recommended plugin to container file manipulation.
SuperContainer The easiest way to upload, view, and download files to and from any FileMaker database, plus it offers numerous advantages over FileMaker's built-in container field: faster speeds, smaller file sizes, web browser uploads, and cross-platform file path compatibility. Single server deployment with unlimited number of users $695
Is the only solution?
Do the container fields need to have external storage specified?
What if you use a shared directory on the server and use the "store a reference" option when inserting the files. Will they then export faster?
Unfortunately the files are currently all local and I am trying to consolidate them on to the server. If I store as a reference than they stay on the users pc. Is that correct?
That is not necessarily correct. You can use container fields to move a file from the user's machine to a shared directory on the server, then re-insert them "by reference" from the new location. That seems to work very quickly with FileMaker 10 and 11 where you do not have the external storage option to use.
I have not tried this with FileMaker 12, so don't know if it will be any faster then the external storage option, but it may be worth a small test to see if it is any quicker.
Attacking this issue from a different angle, why do you need to export the file from the container field? (Maybe there's an alternative to exporting it that we can use.)
The idea is that a user will perform a search, find what they are looking for and then export the hi res image to use it in creating a new style of clothing in Photoshop. What will the script look like to to transfer it to a reference on the server?
First you need the file (or a reference to it) inserted or imported into a container field. You can script this or leave it as a manual operation. Let's assume the image file has been inserted into a container field named: Images::ImageFile. The script to copy that file to the server and then update this same container field to be a "by reference" image linked to the file on the server would be patterned after this script:
Set Variable [$FileName ; value: //put expression shown below here ]
Let ( [T = GetAsText ( GetValue ( Images::ImageFile ; ValueCount ( Images::ImageFile ) ) ) ; //this works for all insertion methods except Insert Object
L = Length ( T )];
Right ( T ; L - Position ( T ; "/" ; L ; -1 ) )
Set Variable [$Path ; "file:/X:/Image Files/" & $Filename ]
Export Field Contents [ Images::ImageFile ; “$Path” ]
Go to Field [Images::ImageFile] ---> make sure focus is in container field
Insert Picture [reference ; $Path]
Note for $Path, I have used a Windows example. A different path using a volume name is needed for mac systems. using the example given, you'd need a shared directory named "Image files" on your server mapped to the drive letter X: with write privileges on that folder for the user in order for this to work. (Those extra details are why "external" storage was added in FileMaker 12 as a way to make this possible without so many system specific details needing to be set up correctly on every user's computer.)
The print records are initially created by someone. That is when the images are initially uploaded to the database. Multiple image types are uploaded to the record and then stored externally in the database.
Would I add this to the import script? And if so, would it delay the process or would it happen on the server where the files are being processed?
The script where I cribbed this from runs in FileMaker 10 via FMS server 10 and uses an Import Records script step to pull all the images from a designated folder (I used a short cut to a folder inside the Documents folder), so it does exactly that, it imports the images and then loops through the found set of new records to move them to the server and re-insert them.
But this is in FileMaker 10, not 12 and we are only dealing with a small number of files at any given time.
In your case, I suggest setting this up as a test and see how it works for you with your actual files.
It may also be worth posting an Issue Report on this in the Report an Issue portion of this forum. It might be interesting to see if the FileMaker Techs have any corroborating reports indicating that the speed at which image files are exported from external storage is a known issue or not. I would definitely recommend that if you find that my suggested work around is much faster than using external storage.
Found a solution.
Moved the database to a new server and it's working much better now. I was running the database on a virtual server and large files were a problem. Thanks for yor help.