auto emails from Access using Outlook (1 Viewer)

[DNewman]

Access 2010 - full version on Windows 7, Runtime on XP
I have an application that populates a table, opens a report with that data and saves and stores it as a PDF. The application then uses an Outlook template to create an e-mail, attach the pdf and mail it.
Spasmodically, and more so on certain PC's, the attachment is sent with some key fields blank.
I have even tried displaying the report so the user can check that all fields are filled before finally sending it.
Unfortunately (an understatement) the report can show all the fields dutifully filled but there are still blank fields in the PDF that is emailed.
ANY suggestions would be really welcome - either re creating the PDF or re using Outlook with Access.

 

[Minty]

How are you creating the PDF - what is the code?

 

[DNewman]

If Dir(strFullFilePath) = "" Then
'Save as pdf if confirmation letter directory exists
DoCmd.OutputTo acOutputReport, "BOOKING_LETTER_EMAIL", acFormatPDF, strFullFilePath
Else
MsgBox "Confirmation Letter already exists", vbExclamation, "ALREADY CONFIRMED"
End If

 

[Minty]

That all looks okay. In later versions of Access (2007 onwards) you can add , , , , acExportQualityPrint to the code to improve the pdf quality, but I doubt that is your issue.

I would look carefully at your data - is the missing information repeatable? e.g. if it misses some data and you delete / move the file and redo the action does it still miss the same fields?

 

[spikepl]

Do you change fonts, background colour or foreground colour from defaults?

Are you sure the fields are blank and do not contain characters of same color as background (try to select the text in pdf with cursor)?

Has this feature always been there or did it begin at some stage?

 

[HiTechCoach]

It may be a font issue. Check the controls that are not displaying in the PDF and make sure they are sing the dame font as the controls that work.

 

[DNewman]

Many thanks for the suggestions.
In fact the problem seemed tohave come from my using dlookup() in the Report Load event - I have now created a query to pull all the fields together into one recordset and that seems to have solved the problem.

 

[HiTechCoach]

Many thanks for the suggestions.
In fact the problem seemed tohave come from my using dlookup() in the Report Load event - I have now created a query to pull all the fields together into one recordset and that seems to have solved the problem.

Glad to here you found the issue.

I find it best to use the report's record source, a query, to lookup all the related data. That uses the power of a Relational Database to do all the work with no VBA code required.

I would only use DLookup() to get unrelated data to the report's record source. I generally avoid DLookup for performance reasons. If possible, I use a sub report.

 

[The_Doc_Man]

It occurs to me that the problem might be related to what you do in which mode. If you do ANYTHING in the report's VBA code, you have to know that certain things only fire when in Print Preview mode (OnPrint events?) and certain other things only fire when in Report View mode (OnFormat events?). Which is why pre-building the contents query BEFORE you involve a report might be helpful in this context. Fewer mode-dependent events means more reliable report creation.

 

[HiTechCoach]

The_Doc_Man makes a great point about the differences in Report View and Print Preview. Report View can be a challenge.