Cross-database calls to DoCmd.OutputTo for PDF or XPS output fail.

[Guest]

I have found what appears to be a bug in the Save as PDF/XPS add-in for
Access 2007.

Given a scenario where VBScript in a database containing a report calls code
in another database (via a reference) in order to generate report output in
either PDF or XPS format, the called code generates the following error upon
attempting the DoCmd.OutputTo method:
Run-time error '2509':
Microsoft Office Access cannot find the object 'reportname'

I have no problem outputting to other file types, such as TXT or RTF, nor do
I have any problem generating XPS or PDF output from code in the database
containing the report.

For instance, given the following two functions, contained in a referenced
database (used as a common function library):

Public Function testRTF(rName As String, destFile As String)
DoCmd.OutputTo acOutputReport, rName, acFormatRTF, destFile
End Function

Public Function testPDF(rName As String, destFile As String)
DoCmd.OutputTo acOutputReport, rName, acFormatPDF, destFile
End Function

The first function succeeds when called from the database containing the
report, but the second one fails with the aforementioned error. There is not
problem, however, executing a DoCmd.OutputTo to PDF format from code actually
contained in the same database as the report.

Can anyone else confirm this and suggest a workaround?!

I have confirmed this problem on two vastly different installations (one
Vista, one Windows 2003).

 

[Guest]

I've seem to have discovered a workaround to my own problem.
It seems that opening the report in preview mode (DoCmd.OpenReport rName,
acViewPreview) prior to calling DoCmd.OutputTo acOutputReport, rName,
acFormatPDF allows the add-in to resolve the report name and thus work
correctly. I would guess that this would have something to do with open
reports being present in the Reports collection. The add-in is probably
checking the Reports collection of the Application object (instead of the
Documents collection of the calling database (currentDB) or the AllReports
collection ofthe CurrentProject object).

 

[krissco]

I have found what appears to be a bug in the Save as PDF/XPS add-in for
Access 2007.

Given a scenario where VBScript in a database containing a report calls code
in another database (via a reference) in order to generate report output in
either PDF or XPS format, the called code generates the following error upon
attempting the DoCmd.OutputTo method:
Run-time error '2509':
Microsoft Office Access cannot find the object 'reportname'

I have no problem outputting to other file types, such as TXT or RTF, nor do
I have any problem generating XPS or PDF output from code in the database
containing the report.

For instance, given the following two functions, contained in a referenced
database (used as a common function library):

Public Function testRTF(rName As String, destFile As String)
DoCmd.OutputTo acOutputReport, rName, acFormatRTF, destFile
End Function

Public Function testPDF(rName As String, destFile As String)
DoCmd.OutputTo acOutputReport, rName, acFormatPDF, destFile
End Function

The first function succeeds when called from the database containing the
report, but the second one fails with the aforementioned error. There is not
problem, however, executing a DoCmd.OutputTo to PDF format from code actually
contained in the same database as the report.

It's interesting that one succeeds and the other doesn't. It almost
sounds like the Application object is getting confused. You might try
passing the application that contains the report to the function:

Public Function testPDF(rName As String, destFile As String, optional
myApp as Access.Application)
if not myapp is nothing then
myapp.DoCmd.OutputTo acOutputReport, rName, acFormatPDF, destFile
else
DoCmd.OutputTo acOutputReport, rName, acFormatPDF, destFile
end if
End Function

Now change calls to the function (depending on the calling context):

call testPDF("rptSomething", "\\path\filename.pdf", Me.Application)
OR
call testPDF("rptSomething", "\\path\filename.pdf", Application)


Hey, it's worth a shot!

-Kris

 

[Guest]

Thanks, but this doesn't make any difference. The code sees the same default
Application object regardless of which DB it resides in (it's
Application.codeDB property that changes when control passes from one DB to
another).

In any case, I did find a workaround, as noted in my reply to myself dated
7/18, which I briefly repeat herein:
It seems that opening the report in preview mode (DoCmd.OpenReport rName,
acViewPreview) prior to calling DoCmd.OutputTo acOutputReport, rName,
acFormatPDF allows the add-in to resolve the report name and thus work
correctly. I would guess that this would have something to do with open
reports being present in the Reports collection. When the add-in can't find
the
report in the DB from which it's being directly called, it's probably
checking the Reports collection of the Application object.