I see nothing here that would change with the change in versions. Have you confirmed that $DocPath is getting the expected file path as passed to this script as a script parameter?
Is the Documents::Document container field present on the Documents_dev layout and browse mode accessible?
Note: if you use file: instead of imagemac: or imagewin: you get a file path calculation that can work for mac or windows and that is consistent with Insert File.
But since you are using FMP 13, you can also set up an interactive container field on your Documents_Dev layout and use Insert PDF instead of Insert File.
I did watch this script in both V12 and V13 and all the variables were set the same, just the insert file step doesn't put the pdf in the container.
The Documents::Documents container field is present. It starts blank with New Record and turns dark grey with insert file.
it could be due to the imagemac: tag--which is what is used with Insert Picture to insert an image file. It may be that this will work if you use file: instead of imagemac:
This database is hosted on our server. If I make this change, will it still work for our existing V12 clients?
it should. If you are using insert file, then imagemac: or imagewin: really shouldn't have worked in the first place when using Insert File and I am surprised that it did.
You can also probably just leave this tag off altogether. My experience has been that some older versions need it but that the newer versions seem to work just fine from filepaths that don't have any such tag: text at all.
If you want to be extra cautious, modify a back up copy of your file, temporarily host it from your server and test it to see if the modified copy works.
I did a lot of test around this and they confirm Phil's statements.
However, it seems that "imagemac:" tag should work too and thus, remove it should not solve the problem.
On the script above, I see the Set Error Capture [On] step. What about if you temporary turn it [Off] ?
Or better, you could insert a Show Custom Dialog Step just after the Insert File step with a Get (LastError) as a calculated message, just to see a precise number of error if any.
Maybe it can provide some details about the problem ?
As per Fred's request I turned off the error capture and added the custom dialog.
The get(lasterror) returned 0
But I did narrow down the problem. Today is a blizzard here so I'm working from my home office. I run Mac Pro's at both offices and both are running 10.9.2. I had a copy of this same database template I use for another company so I decided to test with it. It worked fine, no problems. So I opened the database that was causing the problem and tried again, it failed.
So what is different that effected the results. This solution requires the database to be remote. With the "working" implementation, both the server and client were on the same machine and both were running 13.0.v1. The failing solution is using 13.0.v1 as the client (OS X 10.9.2) and 184.108.40.2067 as the server (OS X 10.8.5)
With the implementation that fails, I tried changing "imagemac" to "file" and the results were the same. I tried it with no tag, just the file path and again it failed.
Well done guy, you found the cause ! That is, it fail whenever the server is 12 and client is 13.
Try to define an external storage on the field's option (secure or not).
It worked fine during my own tests. More info are available on PDFs not interactive in container fields.
Thank you for your posts.
We are tracking an issue with the inability to insert a PDF file into an Interactive Container field when the file is hosted in FileMaker Server 12 and accessed by FileMaker Pro 13. This only occurs under Mac OS X. If the PDF file is inserted with FileMaker Pro 12, then it will work. Also, if you are using FileMaker Pro 13 with FileMaker Server 13, it will work.
One user did get this working by changing the Container format from Interactive content to Image, and then back again.
I have attached this forum thread to the original report. When more information becomes available, I will let you know.