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: Newest
Most helpful Newest Oldest
  1. Anonymous
    2017-05-30T21:29:49+00:00

    Thanks, Heinzi - you've been really helpful :-)

    Was this answer helpful?

    0 comments
  2. Anonymous
    2017-05-12T09:42:15+00:00

    A question - if they have Access 2016 AND 2013 Runtime installed on the office machines, would the .accdr that I supply them with run in Access 2016, or 2013 Runtime?

    That depends on which Access version most recently registered itself as the system-wide accdr handler. Usually, this is the Access/Office version which was most recently installed or repaired. Unfortunately, is something that can change suddenly without your intervention (for example, when Windows Update installs a patch for a particular Office version).

    Thus, I would strongly recommend to create a shortcut to your application (on the Desktop, in the Start Menu or in the Task Bar, whatever your users prefer) which explicitly starts the Access version you want to use and supplies the path to your accdr file as a parameter.

    Best regards

    Heinzi

    Was this answer helpful?

    0 comments
  3. Anonymous
    2017-05-11T23:44:28+00:00

    Hi Heinzi - thanks for this. We upgraded our office machines to Access 2016 because the last version of the application that I sent them when they were using runtime 2010 had issues, probably because I was developing using 2016. We deleted Runtime from the machines to be sure that the full version of Access was being used to run the .accdr. We didn't try 2013 runtime. I still send them .accdr versions to stop all the the Access menu bars etc from being displayed , which they would do now they have a full version of Access on their machines (my application has a main menu with all the options they need).

    A question - if they have Access 2016 AND 2013 Runtime installed on the office machines, would the .accdr that I supply them with run in Access 2016, or 2013 Runtime?

    Thanks for being so helpful :-)

    Was this answer helpful?

    0 comments
  4. Anonymous
    2017-05-11T20:22:26+00:00

    Hi Pete!

    Is there a workaround, or a fix in the pipeline?

    To the best of my knowledge, these are the only workarounds currently known:

    1. Install the Access 2013 Runtime and use it to run your application. The Access 2013 Runtime can be installed alongside Office 2016.

    Downsides:

    (a) This option won't work for Terminal Server situations, where multiple Office versions on the same system are not supported.

    (b) If you use the MSI version of Office 2016 (e.g. the volume license versions), every time you switch between Access 2013 and Access 2016, an short "installation" occurs and wastes about a minute of your time. The CTR version of Office 2016 (e.g. Office 365 or the retail versions) does not have this problem. 2. Downgrade to Office 2013. 3. Use an accdb file instead of accde or accdr (which obviously reveals your source code) and don't use the /runtime flag.

    Since 3 is not an option for us, we tell our customers to use 1 where possible (i.e., everywhere except for Terminal Server installations) and 2 otherwise.

    According to Mike Sullivan's post (see above, April 14), Microsoft is actively working on a fix for this issue.

    Best regards

    Heinzi

    Was this answer helpful?

    0 comments
  5. Anonymous
    2017-05-11T13:47:02+00:00

    Not just a runtime update, Andi - an .accdr running on a full version of Access experiences the same issue.

    Was this answer helpful?

    0 comments