Access 2016 accde "DoCmd.OutputTo acOutputReport, , acFormatPDF..." crashes after 10 minutes

Anonymous
2016-01-24T09:19:56+00:00

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.

Microsoft 365 and Office | Access | For home | Windows

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.

0 comments

75 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Anonymous
    2017-05-06T10:39:37+00:00

    I'm wondering if my issue is the same bug, and if the symptoms might help.

    My office runs an application that I've written. They tell me that when the output a report to PDF using my 'save' button, the aplication crashes (I'm using DoCmd.OutputTo acOutputReport etc). They then restart the application, and they can successfully use the same button to save the report to file. If they then use a different machine (we have three machines with the same front ends), the same thing happens - first time the application crashes, next and subsequent time it works fine.

    I haven't asked them to time it, but at some stage later in the day, the same thing can happen again. The office machines are using .accdr front ends but with full versions of Access (the only way I found to not let them have access to all the Access controls, but that's another thread!).

    At home, in my office, I have the same version of Access, front and back end computers networked together to emulate the office environment, but I can't get the application to crash, using either .accdb or .accdr versions of the front end.

    Was this answer helpful?

    0 comments
  2. Anonymous
    2017-05-06T10:40:51+00:00

    sorry - we're using Office 365, so Access 2016

    Was this answer helpful?

    0 comments
  3. Anonymous
    2017-05-08T08:41:51+00:00

    > I'm wondering if my issue is the same bug, and if the symptoms might help.

    Sounds like it.

    > At home, in my office, I have the same version of Access, front and back end computers networked together to emulate the office environment, but I can't get the application to crash, using either .accdb or .accdr versions of the front end. 

    What happens if you start the accdr version of your application, take a very long coffee break (at least 80 minutes) and then return and output a PDF?

    Best regards

    Heinzi

    Was this answer helpful?

    0 comments
  4. Anonymous
    2017-05-10T13:15:34+00:00

    Hi Heinzi - I'm running this test now. I'll report back in 85 mins - Pete.

    Was this answer helpful?

    0 comments
  5. Anonymous
    2017-05-11T13:25:10+00:00

    Sorry - I had to leave the test until today. I fired up the .accdr, printed an invoice to PDF, left the .accdr running for 85 minutes and then tried to print to PDF again which resulted in my application and Access closing down, virtually instantly, with no visible error message, leaving me staring at my desktop. I guess that confirms that we're suffering from the same Access bug. Is there a workaround, or a fix in the pipeline? Thanks - Pete

    Was this answer helpful?

    0 comments