Nothing obvious comes to mind. Your setup seems fine.
Couple of debugging things to try:
Can you temporarily redirect the path to their desktop folder or their temp
directory. This will likely rule out any unusual permissions problems.
I know you say you are saving to the user's documents folder, but I have
been caught when the path actually points to a mounted volume that drops
off for some reason. Not trying to tell you to suck eggs but sometimes it's
the obvious that we miss.
Anyway, just a couple of things to try.
Bromac Business Services Pty Ltd
P: +61 7 3208 9411
F: +61 7 3910 1092
TFP Cooperative Limited
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message, which arise as a result of e-mail
transmission. If verification is required please request a hard-copy
*Please consider the environment before printing this email - every year we
are losing 40 million acres of oxygen producing forests through logging and
Curious as to when the variable gets defined. Does the Save Records as PDF step immediately follow it?
Also where is it getting the info for the variable? Picking it up from a field?
Just throwing out some thoughts..:)
I have a client who has random issues with Save Records as PDF, but we have found things like "/" or a return at the end of an entry in a field from which the define variable (filename) is derived. However rebooting does not clear it up for them. They still get the same error after a reboot.
We are also on Mac and have this problem on occasion, it is normally just a case of ensuring that the 'drive' you are saving it to is visible in Finder. We use a separate fileserver, so don't normally have to restart FM, just ensure that the folder you are saving the documents to is visible and try the save again.
Cheers ... IAN
There use to be a problem with Adobe PDF libraries conflicting with FileMaker PDF functionality, but we should not have it in FM13 and I haven't seen Acrobat on a MAC for ages, although they are still doing new releases.
I would suggest creating a log field and adding a script step to log errors and relevant information on PDF creation. Error trapping never hurts (OK, this is not true). This could give you some vital clues.
Depends on the investigation outcome, I would probably try to trap an error and and print it again using an alternative. E.g. instead of Save as PDF use Print with Save to PDF as print setup. If it does not work, I would start looking at AppleScript.
If this behaviour happened all the time for these users I'd say the problem is a permissions issue. It still could be, so I'd check that anyway, though I don't know why it would only trip them up occasionally. In my experience you (or they) as the owner/user must have read/write permission for the folder(s) the script accesses, and you also must have read/write permission for either/both of fmuser and fmserver.
That aside, if this only arises occasionally I'd suggest it most likely relates to content of the filepath variable that is set—the sort of thing Lynda has already suggested: rogue characters, spaces or carriage returns; specific characters that will be misinterpreted by the OS or FM such as /, @, etc.
On the other hand, if these users get tripped up, then restart, then can save the pdf on the same record that tripped them, the issue might lie elsewhere, though exactly where to start I can't think at present.
I'd say the problem is a permissions issue
this is more likely to happen on Windows, if NetAdmin is a bit over overzealous. On a mac it is usually not a problem, unless you are saving to shared network drives or using hidden folders like /var or /etc, especially at the root level. Re-directing output to the desktop like StanMillar suggested should exclude folder access issues. It is better than temp as I did see before administrators locking the parent directory of this folder.
you also must have read/write permission for either/both of fmuser and fmserver.
Are you sure? I know you need them on the server, but I can't ever remember setting any local users to match any of them.
I agree fmserver permission is needed only if Server is involved, but I think you need fmuser permission when the pdf is being created by script. Of course I may be wrong.
As regards Mac permissions, I have certainly run across issues occasionally if a folder doesn't have correct permissions.
Following from Lynda and Keywords, add a tab to that list.
I auto enter Trim(Substitute(Self;¶;"")) the field to stop the returns, spaces and tabs from sneaking unnoticed onto the ends of the string when the operator adds a space or tries to go to the next field with tab or return.
Back in FM11 or 12 I had to sometimes add a pause of length zero immediately before the save as pdf step but I don't think it was the disc error message, it just bypassed it.
The naming convention is simple, no crazy characters, just alpha characters and a timestamp.
Just in case - Has the timestamp component had its "/" and ":" characters substituted out?
A couple of thoughts...
1] Trap for the specific error that occurs when the print to PDF fails. That may give you a clue. If not on the computer with FMPA installed, add a set variable step for $error and then a step to set $error to Get(LastError). I then have it display in a custom dialog message - that way you can see what the number was and go from there in searching out the issue. (I've found -sometimes in schools - the setting on the computer by the IT staff does not allow the user to save in certain folders - for whatever reason.)
2] A second idea you might try is to reduce the process to its simplest form. I start with a new script with just the save to PDF step and the location(desktop) and path of the file with name entered in the Specify Output file. If that works, then add the step where the path and name are entered as a variable, then the variable is used instead of the specified path. If that works, then you might copy all of that into your script, disabling the same steps in the script. I've found for some reason the save to pdf, export, etc. steps seem to be corrupted and just don't operate as they should. I think its something I just don't see that is wrong, but taking the process to the basics almost always solves the issue.
Hope this is helpful,
You would be wise to make sure that the filename it's trying to save to is a valid filename. I see this often in Windows and occasionally on the Mac when someone puts an invalid character in a field that will eventually be saved as part of the filename.
On the Mac, usually the only thing that will throw it off is a . or a :
On Windows and of these: / ? < > \ : * | " will dump it.
So you might want to make sure that you don't have this because it won't ever say "invalid filename" like it would if you were trying to save it, the Scripts will error out with unable to save.
I'm building the first variable ($filename) like so, to avoid random whatnot -
"Quote " & Month ( Get ( CurrentDate ) ) & "-" & Day ( Get ( CurrentDate ) ) & "-" & Year ( Get ( CurrentDate ) ) & " " & Hour ( Get ( CurrentTime ) ) & Minute ( Get ( CurrentTime ) ) & ".pdf"
The second variable for $volume is set using the Get (DocumentsPath) to user ~/Documents to insure writeability. I've also redirected that to the local desktop, and their sales share with same (irregular) behavior.
Third variable $attachment is used in Send via Email Client and is simply $volume & $filename
After all the comments (thanks everyone!) I'm thrown back into thinking that it's indeed a permissions problem since it's not repeatable after a restart, in the same record, and not anything to do with Filemaker.
I'm going to boot both Macs to single user and run Applejack. I'd previously run Disk Utility in the GUI.
I'll update this thread soon either way. Thanks all!
This is an 'issue', and has been reported quite a bit, by me in particular. It affects FMP13 on OSX.
It IS an FMP 13 thing, if you open the same file in 12 it never exhibits the behaviour, and it is to do with FileMaker erroneously thinking the file is opened in Reader. Clearly you can't save a file to one that is already open... BUT once whatever flag has been set internally is set, you can't get out of it without restarting at least FMP, and in some cases the machine.
Given that Preview on the Mac is NOT a standards compliant PDF renderer that is a cause of a lot of frustration to those that do advanced work with PDF files, so use decent tools to work with them
Please go to Community Home . Pages . FileMaker Forums and find any of the threads on this issue and add your voice. It is quite mission critical of some of us and requires a proper solution.
AHA! thanks, J. I will certainly do so. My search didn't bring up those previous discussions, I will add my voice.
And in the meantime change the default reader back to Preview, sad as it is.