4 Replies Latest reply on Jul 10, 2012 9:22 AM by j_bell

    Mac/Windows file path issues with Container fields


      Wondering if anyone can help me out with a little issue I can't seem to resolve. I work in an environment where we have both Mac and PC users that will both be accessing the Filemnaker database. The Mac users are our design and production section and the PC users are our PR people that deal directly with the clients. Our design area creates artwork and saves it into a PDF format for the PR people to sho to the client. Up till now this has all been done through email but with our upgrade and redesign of our database we would like to store a link to these PDFs under the correct job number in Filemaker so all can have access to it.


      The iisue I am having is that if I use a Container field and one of the designers on the Mac inserts the PDF into the container field and a user on the PC double clicks to open it (and vice versa PC to Mac), they receive the message of file path not found because PC and Mac read the paths differently. Unfortunately hardware wise there is nothing I can do to change the Mac/PC thing so I need to come up with a solution using Filemaker.


      Any help would be appreciated.




      PS.sorry for the long winded message.

        • 1. Re: Mac/Windows file path issues with Container fields

          Hi, Jamie.


          Common problem. There are a few solutions:


          1) If you're using FileMaker 12, set your solution to store the data externally (under Manage Database / Options / Storage). This will cause FileMaker to push the data into a specified path, either on the hosting server (preferably) or in the same directory as the database (not preferred).


          2) Use a third-party application called SuperContainer from 360Works (www.360works.com). This handy little tool allows you to program a web viewer to do largely the same thing as the externally stored containers. It also works in versions prior to 12, so if you're not on 12 yet, this will still work.


          3) Store the data internally to the database. Not the best idea, as it contributes to database bloat, but it will work cross-platform.





          1 of 1 people found this helpful
          • 2. Re: Mac/Windows file path issues with Container fields

            Thanks Mike, this helps. We are about to migrate from 11 to 12 so once it has been installed I can give the first suggestion a try. I am deifinitely going to look into the SuperContainer solution it may be what I am looking for. Option 3 in this case wouldn't work for us as the file sizes average 2-3 megs and we do upwards of 1000-1200 jobs in a year. The database wouldn't just bloat I think it would explode!!  LOL


            I really appreciate the suggestions.



            • 3. Re: Mac/Windows file path issues with Container fields

              Jamie --


              or probably the most difficult:


              4) Create a calculated text field that uses GetAsText ( Referenced Container Field ) as part of the data and create a new, unstored, file path based on Get ( SystemPlatform ).  Then, create a new container field which is the one you display.


              You have to work out the file paths based on platform and your own internal file structure. 


              I've done this using the Troi File plugin, but it should probably be possible to do it within FileMaker Pro.


              I'm also assuming that the person who created the linked file also places it on some shared folder on the network first, then creates/updates the FileMaker record for it.



              I really prefer the new 'Managed Container' option in FM12, though.  It takes away almost all of the work, and the files become pat of the database backups from FMServer as well.


              -- Drew Tenenholz

              • 4. Re: Mac/Windows file path issues with Container fields

                Thanks Drew.


                You are correct. The designer is working from a shared server and the link to the file would be to that server, not a local hard drive. I will also give your suggestion a try (using the calculation) as finding a solution within Filemaker itself may be my best bet at this moment in time as my hands are also a bit tied with our IT department as they control what software goes on the machines. It is really sounding like we need to move up to 12 though based on the couple of comments here and some of the other postings I have been reading throughout the forum.