I'm a bit confused by your description of your issue. Your references to:
a file structure alongside the database
a different file structure on the local drive
Suggest that you are not actually using external storage but are inserting images with the "store a reference" option enabled.
images dropped onto container fields
means that you are using drag and drop to add images to container fields, you are not using "store a reference" as this action copies the physical file into the container field. If this container field then has external storage specified, FileMaker copies the image from the container field to the specified external storage folder and is supposed to then update the container field to contain a reference to this external storage location.
From what you describe, that would seem to be what you are doing in 1. above, but please confirm that I am correct...
But exactly what do you mean by item 2? Do you have external storage setup to specify a location on the local drive? if so, I can see why that wouldn't work. Are you inserting or importing with "store a reference" specified? Again, I can see why that would not work.
For a hosted file where the images need to be accessible to all users on all devices, you need the files located on the server--whether using External Storage or "store a reference". And External storage is less problematic to implement than "store a reference".
Yes, the description of item 1 is correct, and it works fine, either locallly or hosted.
The issue I have is item : In this case the cintainer is set up simply as a window to a files on the drive, and not used to insert images. In the same directory as the databse resides a folder (called imagefiles) that contains images that have been uploaded to the host. They have NOT been inserted into the database via drag and drop as in item 1. The databse has a calculation field whose result is a container which should refer to a specific file inside 'imagefiles', enabling the image to be viewed inside the database. When run locally this solution works fine, but I am unable to get the correct snytax in the calculation field to enable images to be visible in records via the calcutaled container field when the database (and 'imagefiles') is hosted.
Am I trting to do something impossible?
When you move the file and images to your server, two possible issues occur that will need to be overcome:
One is that every user will need "Read" access to that folder--which is probably not the case if you are using Server to host the database and the images are all located in the same folder as the hosted DB file.
The filepath to that folder must be exactly the same for every user and you probably need to mount/map that folder on every client machine as well. If so, that map/mount has to be set up identically on every machine. (I know that if you use an explicit file path as opposed to a relative file path, you'd have to do this.)
Why are you not using a container field with external storage for this particular field?
That would seem a much simpler option and I'm not able to imagine an advantage to that over using your calculated container field instead.
Access permissions are ok, and everyone can "read" the images and the containing folder. These are the same permissions as for the files that are created on the host via drag/drop onto a 'type 1' container field.
I can see your point regarding the need to mount/map the folder, but I have one question: Given that FM on the host can accept images via dragging & dropping onto a normal container field, and then have those images visible to all users of the database without mounting/mapping the enclosing folder that FM created for the images in directory that contains the database, why can this not be done using a calculated container field referencing some images that have got onto the drive via a process that is not dragging onto a normal container field? This is kind of like using the process in reverse (which works fine locally).
Your question: why not use a container field with external storage? The images are associated with survey forms, and there are several Databases that access the same folder of images (a given image may be associated with >1 record, in >1 database). At the moment the images are loaded daily onto the local drive and the calculated container field works out which image should be displayed on any particular record in whatever database, via the image name / subfolder location. If I used a container field with external storage I would have to associated images with each record in each database manually, which would be time consuming and more importantly introduce further possibilities for human error. The process is ongoing and there are to date about 8,000 records (spread across 6 different databases) accessing about 25,000 images.
I think this issue for you becomes how the path is calculated. Those calculations are preformed relative to the client accessing the information. So for example, because the Filemaker is in charge of the connection to the path to the stored files, it knows how to reach and post those files into the current container. And because it's relative to the database, it's the database that is serving those files.
However, when you use external storage, that is outside of filemaker's control, the path to the files is different, from the Client's perspective. So when you go to the files, and you tell the client to look in a certain location for a file, the client has to know where and how to get to that file. Whereas when filemaker is servicing the files, filemaker handles that differently.
This is why you would have to map/mount the network paths on the client machine. If they are Macs, you could actually do it for them if you had administrator access to the machines via an account you could script the Mounts with the Perform Applescript Step and then an accompanying applescript. However in Windows, things get more difficult to do that.
These are the same permissions as for the files that are created on the host via drag/drop onto a 'type 1' container field.
That will not be the case as files drag/dropped into container fields are copied into the container field. No access to a folder on the server is required in that case. If this file is hosted on the server, the folder holding the database file is generally, not accessible to the average user and really shouldn't be for security reasons.