This is a nasty one caused by the fact that container fields store a different filepath for mac systems than for windows systems.
A typical mac format filepath is: imagemac:VolumeName/foldername/foldername/filename
A typical windows format filepath is imagewin:DriveLetter:/foldername/foldername/filename
There are two basic requirements that must be met before the image will be visible in the container field for a given client computer:
1) The directory where the image file is stored must be shared and accessible with at least "read" access permission.
2) The file path to that shared directory when it is mapped/mounted must be exactly the same path as that stored in your container field.
There are several solutions to this issue that you can try:
1) define a calculation field that returns "container" as its return type. Construct a text calculation for this field that uses the client's platform and the filepath stored in your current container field to construct a filePath that is valid for the current user. You may want to examine the text currently stored in your container fields when a file is inserted from both platforms to see how they differ and how they are alike in order to construct a calcualtion that works. To do this, you can use the dataviewer with GetAsText(containerfield) if you have FileMaker Advanced or you can place a calculation field that returns text and has the container field as the only term in its calcualtion on a layout next to the container field and that is sized several lines of text tall.
You'd keep your original container field for data entry and use this calculation field for display purposes.
2) (Only practical if you have just a few image files where you have this issue), Define two container fields and insert each image twice, once from each platform. There are then a number of ways your system can detect the current platform and use that info to control which container field is displayed. You can have both fields in different tab controls, on duplicate layouts, as records in a portal where a portal filter or the relationship controls which container field is shown...
3) Use a web viewer instead of a container field to open and display the image.
4) (Costs $$$) take a look at the SuperContainer 3rd party product as a possible alternative approach.
Thanks for the quick response. I will try to make this work without causing too much grief. Has this always been an on going problem across platforms when using pointers to files?
Yep, With FileMaker 12, you have an external storage option for container fields. I'm not sure if offers any improvement when dealing with this issue or not...
If I chose to not use a pointer and instead just load the files into the database ( which would work on both systems ), what would be a size too big for a database using that format? Considering I only have about 1,000 images.
There's no definite limit. It will depend on the size of your image files (2 meg or 300 meg?) the design of your layouts (Only one image at a time or in a list or portal with 10's, 100's or more at one time?), the speed of your network connection (LAN, WAN, IWP...), Your processor speed (iPads and iPhones are MUCH slower than most recently produced full up computers), the speed of your server's hard drive and the version of FileMaker that you are using (FMP 12 is MUCH slower in many situations than FMP 11.)
Ultimately, you may need to make a copy of your file, change it's design from "by reference" to "embedded" files and test your system to see what happens.