Output to PDF unreliable (1 Viewer)

[DNewman]

I am using Access 2010 runtime on both Windows XP and Windows 7 to create a .PDF from a report using the OutputTo function in VBA. The back end database is on a nas drive.
I am finding that the result is unreliable - text fields are sometimes left blank and (very infrequently) a particular field is actually incorrect (though a possible result).
(1) Any suggestions for improving the OutputTo function? I may have totally misread the situation but I wonder if the OutputTo function runs too slowly and can't complete before Access 'moves on'.
(2) Is there a more reliable alternative to OutputTo PDF?

 

[Minty]

If you preview the report are you absolutely certain that the unreliable results are not there? What code are you using to do the OutputTo ?
The other option is to print the report to a pdf Printer - Bullzip, Primo, there are numerous ones about, but that would mean ensuring the pdf printer is installed on every machine

 

[Ranman256]

Access won't move to the next statement until OutputTo is complete.
Are you sending a form or a report?

 

[DNewman]

Thank you for responses:

Minty: I am using

DoCmd.OutputTo acOutputReport, "BOOKING_LETTER_EMAIL", acFormatPDF, strFullFilePath, , , , acExportQualityPrint

I have tried previewing the report but it always shows all the controls filled in correctly so I assume the problem is with the OutputTo

Ranman256 I suspected that, I am sending a Report with the above code.

 

[JHB]

What if you put in a brakpoinet in your code, just one after DoCmd.OutputTo. When your code stops at the brakpoinet, then wait 5-10 seconds before you continue.
If the above helps then put in some DoEvents in the code.

 

[Minty]

The other thing is what is the report based on and are any of the items missing in subreports?

I had a weird thing where the recordsource of a sub report wouldn't be correct during OutputTo but was always fine if I print previewed the report directly. I ended up setting the record source for the subreport before opening the main report, and it was fine.

 

[missinglinq]

Access won't move to the next statement until OutputTo is complete.

Actually, Access is asynchronous, which is to say, if given a series of commands, it starts to execute one, moves on to the next one and starts executing it, and so forth. It doesn't wait for the first command to be completed before starting the second one, and this can cause timing problems.

An example would be a button that runs a series of Queries where all but the first Query is dependent upon the previous Query being completed before it starts to execute! The following VBA code

DoCmd.OpenQuery "QueryA"
DoCmd.OpenQuery "QueryB"
DoCmd.OpenQuery "QueryC"

will immediately run all three, not waiting for one to finish executing before starting the next one. The answer to halting the code in this type of situation, as suggested by JHB, is to use DoEvents.

DoCmd.OpenQuery "QueryA"
DoEvents
DoCmd.OpenQuery "QueryB"
DoEvents
DoCmd.OpenQuery "QueryC"

DoEvents returns control to Windows, allowing QueryA to complete running before starting to run QueryB. It then allows QueryB to finish running before starting QueryC.

DoEvents is an easy, safe bet when encountering what seems to be timing issues, which your problem seems to be.

Linq ;0)>

 

[sneuberg]

Actually, Access is asynchronous, which is to say, if given a series of commands, it starts to execute one, moves on to the next one and starts executing it, and so forth. It doesn't wait for the first command to be completed before starting the second one, and this can cause timing problems.

What makes you think this is the case? Can you give us some sources that would back this up? I think Ranman256 got it right, i.e., VBA is single threaded.

It would be convenient sometimes if you could get access to do what you claim it does so easily. If for example you have a query that takes an hour to run, it would be convenient if you could return control to the user so that they could do other things while it was running.