1 2 Previous Next 22 Replies Latest reply on Jan 11, 2017 10:47 AM by iceman7

    Creating a PDF - won't write to disk


      I've searched (thoroughly, I think) on this problem but the answers I got back have turned out not to work - so I'm stumped.


      I've two scripts that are used over and over again throughout the day by the sales staff, that have recently stopped performing reliably. They've been in place since forever, too (when pdf creation by script was introduced - that long - years and years and thousands of pdfs).


      The problem is that both scripts - sometimes - for just these two users - will not write the PDF to disk, giving the user the old "Cannot write file, disk may be full, use another disk, blah blah" message.


      The naming convention is simple, no crazy characters, just alpha characters and a timestamp. The user doesn't have a file open with same name, either.


      The two users in question have plenty of disk space locally (where it's writing, in their documents folder). The scripts are running with full admin privileges. I've repaired permissions on their Macs, tried fresh install of FM 13.0v5, checked for adware/malware, tried redirecting the file from writing to their documents folder to a different directory on their macs, and to a server share that they have write privileges to. Nothing has helped.


      They'll tool through the day happily sending quotes and invoices, then bang, it'll crop up again. Quitting and restarting FM is the only way to get it going again. The user can then return to the record and the script performs as written.


      I've also installed Advanced on one of them, and followed the debugger to the failure at the creation line to no avail -


      Script step: Save Records as PDF [Restore; No dialog; "$_pdfName" ; Records being browsed]


      Users are both on Macs, both on 10.9.5, both FM 13.0v5. Files are being served by FMS 13.0v5. Suggestions are welcome and appreciated!





        • 1. Re: Creating a PDF - won't write to disk

          Hi Tony


          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.


          Stan Millar

          Managing Director

          Bromac Business Services Pty Ltd

          Loan Administration

          w: www.bromac.com.au

          e: loans@bromac.com.au

          P: +61 7 3208 9411

          F: +61 7 3910 1092


          TFP Cooperative Limited

          w: www.tfp.coop


          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

          land clearing.*

          • 2. Re: Creating a PDF - won't write to disk

            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.

            • 3. Re: Creating a PDF - won't write to disk

              G'Day Tony,


              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

              • 4. Re: Creating a PDF - won't write to disk

                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.

                • 5. Re: Creating a PDF - won't write to disk

                  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.

                  • 6. Re: Creating a PDF - won't write to disk
                    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.

                    • 7. Re: Creating a PDF - won't write to disk

                      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.

                      • 8. Re: Creating a PDF - won't write to disk

                        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.

                        • 9. Re: Creating a PDF - won't write to disk

                          mrochie wrote:


                          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?

                          • 10. Re: Creating a PDF - won't write to disk

                            Hi Tony,


                            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,



                            • 11. Re: Creating a PDF - won't write to disk

                              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.

                              • 12. Re: Creating a PDF - won't write to disk

                                Thanks Lynda!


                                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!

                                • 13. Re: Creating a PDF - won't write to disk

                                  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.

                                  • 14. Re: Creating a PDF - won't write to disk

                                    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.


                                    Thanks again.


                                    1 2 Previous Next