A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Setting Up & Running Reports
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

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



 
 
Thread Tools Display Modes
  #1  
Old July 18th, 2007, 07:46 PM posted to microsoft.public.access.reports
Tom Bombdil
external usenet poster
 
Posts: 3
Default Cross-database calls to DoCmd.OutputTo for PDF or XPS output fail.

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).



  #2  
Old July 18th, 2007, 09:38 PM posted to microsoft.public.access.reports
Tom Bombdil
external usenet poster
 
Posts: 3
Default Cross-database calls to DoCmd.OutputTo for PDF or XPS output fail.

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).

"Tom Bombdil" wrote:

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).



  #3  
Old July 19th, 2007, 03:45 PM posted to microsoft.public.access.reports
krissco
external usenet poster
 
Posts: 167
Default Cross-database calls to DoCmd.OutputTo for PDF or XPS output fail.

On Jul 18, 10:46 am, Tom Bombdil
wrote:
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

  #4  
Old July 19th, 2007, 04:30 PM posted to microsoft.public.access.reports
Tom Bombdil
external usenet poster
 
Posts: 3
Default Cross-database calls to DoCmd.OutputTo for PDF or XPS output f

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.

"krissco" wrote:

On Jul 18, 10:46 am, Tom Bombdil
wrote:
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


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 02:43 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.