This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Create PDF in accdb is no problem.
Create PDF in accde crashes after 10 minutes.
Command: DoCmd.OutputTo acOutputReport, , acFormatPDF, strOutputFile, False, , , acExportQualityPrint
At first the DoCmd.OutputTo method runs fine.
But if you do 10 minutes nothing (only opened) and then you try to run DoCmd.OutputTo again, access crashes without error.
It seems like a timer-problem, but there is no timer.
Only by acFormatPDF and only with accde. In a accdb-file all is fine.
It is not a problem of the PDF-Software. I checked several PDF-Software-Products. Additional: Parameter Autostart is false.
So the PDF-Software should do no matter.
It is not a Problem of anti-virus-Software. I checked it also without any anti-virus-Software.
A family of Microsoft relational database management systems designed for ease of use.
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
Thanks a lot in advance.
May this issue soon be solved with a Access 2016 runtime update.
Hello,
I wanted to let you all know that we are taking a look at addressing this issue. Please see the request on our UserVoice site: https://access.uservoice.com/forums/319956-access-desktop-application/suggestions/11678409-docmd-outputto-acoutputreport-acformatpdf-c
Mike
Milestone achieved! Thanks a lot.
This issue has been driving me crazy ever since we upgraded our MS Access database to 2016 runtime *.accde
We have the full version of Access which we run in runtime to protect the code and structure of the database from accident tampering.
After moving to Access 2016 this started happening, and is affecting all our users. Please fix this Microsoft.
Today, I did one last experiment on Office365 Version of Access2016 (16.0.7341.2035) to confirm 80 minutes or more is problematic --> that is, results in app crash upon command to "store report as pdf".
Today's experiment is a simpler experiment than those I've done in the past, which were carried out programmatically. For instance, my March 29, 2016 posting indicates that my experiments have involved a built in pause (of varied duration) followed by a call to a method that stores a report as a pdf. Experiments of those kinds were great for determining precisely when things go unstable, to the second. Yet, they are somewhat artificial and add additional variables (a call to the Sleep method for instance). They leave one wondering: is there some artifact of the experiment responsible for app crash??? To be specific, does this artifact cause an 80 minute threshold for "Office365 version of Access2016" and an "8 minute threshold for MSI Volume License Access2016"???
With these concerns in mind, I devised a simpler experiment, that instead simulates the experience of a user who opens the application, and from time to time presses a button to store some report as a pdf. Clearly, said user might become frustrated if, after the application is open for 80 minutes, the command results in app crash!
So, today I opened the Access database in runtime mode, and every 10 minutes, pressed a button to store the report as a pdf to C:\Temp. As I neared the 80 minute threshold, I issued the command more frequently than once every 10 minutes for the sake of added clarity. I found that, though I could still "store as a pdf" at 78 minutes after opening the app, and 79 minutes after, and 79.5 minutes after, I couldn't at 80 minutes after opening the app! At 80 minutes, the pushing of the button results in app Crash with no pdf created! These findings are consistent with test done programmatically (described in my March 9, 2017 post).
To sum, I have learned that this 80 minute threshold is real. It is not an artifact of my former testing method.
To further sum, we have an 8 minute threshold for Access2016 (MSI, Volume License, 16.0.4456.1003) and an 80 minute threshold for Office365/Access2016 (16.0.7341.2035).
Please note that, in all cases, Access was 32bit and installed on Win10 (64bit).
That is all.