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: Most helpful
Most helpful Newest Oldest
  1. 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
  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-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
  4. Anonymous
    2017-05-03T17:05:52+00:00

    Thank you assembler_x64 for running the test that you did and posting your findings. 

    I agree, an 8 minute threshold makes it a "weird bug".  But, it is weirder still in that, if you have the Office365 version of Access2016, the threshold is 80 minutes!

    From my March 9th, 2017 post:

    "Happens for Office365 version of Access2016 as well as MSI Volume License of Access2016.  However, the "time limit" required for a crash to occur differs!  8 minutes for MSI, 80 minutes for Office365.  Yes, the crash threshold differs by a factor of 10! "

    I do hope Microsoft fixes this bug.

    Alex_891

    Was this answer helpful?

    0 comments
  5. Anonymous
    2017-05-03T14:43:50+00:00

    When i read about this 8 minute issue, i thought this is a joke.

    but then i stopped time on my application. and gues what:

    8 Minutes and it crashes.

    1st: that is some of the more weird bugs (not the most weird) i have ever seen

    2nd:

    More than one year this is a known issue?

    Seriously Microsoft, how can you waste so much time without solving this bug?

    If the source would be public available, someone could fix it.

    Was this answer helpful?

    0 comments