In Access 2007, how do I immediately print a Report to a printer without user intervention?
I am developing an Access 2007 "project" (.adp) as a front-end to data held in a SQL Server 2005 Express database.
Usually, I use the following VBA code to print a Report, giving the operator the Windows "Print" dialogue box to choose the printer they want to use.
DoCmd.OpenReport strReportName, acViewPreview, , , , strLongOpenArgs
DoEvents
ReFocusOnReport (strReportName)
DoCmd.RunCommand acCmdPrint
DoCmd.Close acReport, strReportName
What I would like to do this time is immediately print to a particular printer (defaulted in the design of the Report) without requiring any further intervention by the operator.
I have tried various permutations of changing "acViewPreview" to "acViewNormal" and commenting out some of the other lines, but although I can sometimes get the report to print immediately, some odd things seem to happen in the "Report_Open" and "Report_Load" events of the Report.
Can someone put me right on this, and tell me the best way to get a Report immediately printed, with the "Report_Open" and "Report_Load" events fully obeyed?
Many thanks.
Usually, I use the following VBA code to print a Report, giving the operator the Windows "Print" dialogue box to choose the printer they want to use.
DoCmd.OpenReport strReportName, acViewPreview, , , , strLongOpenArgs
DoEvents
ReFocusOnReport (strReportName)
DoCmd.RunCommand acCmdPrint
DoCmd.Close acReport, strReportName
What I would like to do this time is immediately print to a particular printer (defaulted in the design of the Report) without requiring any further intervention by the operator.
I have tried various permutations of changing "acViewPreview" to "acViewNormal" and commenting out some of the other lines, but although I can sometimes get the report to print immediately, some odd things seem to happen in the "Report_Open" and "Report_Load" events of the Report.
Can someone put me right on this, and tell me the best way to get a Report immediately printed, with the "Report_Open" and "Report_Load" events fully obeyed?
Many thanks.
ASKER
Thanks for the prompt response.
My strLongOpenArgs string contains "TopNNN", "Order By" and "Where" clauses, separated by a "¦" character, which gets parsed and separated out in the Report's "Report_Open" clause. These are used for constructing the Report's "RecordSource" property in the "Report_Open" procedure.
It also has "ThisFormName" concatenated at the end so that I can use a "Forms(ThisFormName).Contr
(The Report is for printing receipts on an EPOS printer in a shop and the calling Form has a "staff member" and "receipt number" already established and I want these printed on the receipts.)
This all works OK if I use the code in my original posting, but I do not want to trouble the operators with the "Print" dialogue Window. I just want the receipt to be printed immediately.
When I have tried changing the code, tracer messages I have placed in the Report's "Report_Open" and "Report_Load" routines sometimes seem to suggest that "Report_Open" gets run twice but does not have the correct "Open Args" values the second time round, which means that the "Forms(ThisFormName).Contr
Hope that sheds some more light on what I am trying to do.
My strLongOpenArgs string contains "TopNNN", "Order By" and "Where" clauses, separated by a "¦" character, which gets parsed and separated out in the Report's "Report_Open" clause. These are used for constructing the Report's "RecordSource" property in the "Report_Open" procedure.
It also has "ThisFormName" concatenated at the end so that I can use a "Forms(ThisFormName).Contr
(The Report is for printing receipts on an EPOS printer in a shop and the calling Form has a "staff member" and "receipt number" already established and I want these printed on the receipts.)
This all works OK if I use the code in my original posting, but I do not want to trouble the operators with the "Print" dialogue Window. I just want the receipt to be printed immediately.
When I have tried changing the code, tracer messages I have placed in the Report's "Report_Open" and "Report_Load" routines sometimes seem to suggest that "Report_Open" gets run twice but does not have the correct "Open Args" values the second time round, which means that the "Forms(ThisFormName).Contr
Hope that sheds some more light on what I am trying to do.
I rarely use the Report_Open event.
Have you tried moving the code that is in the Open event into the Load event? I would copy the report, save it with a new name, and then play with moving the code to the Load event.
Have you tried moving the code that is in the Open event into the Load event? I would copy the report, save it with a new name, and then play with moving the code to the Load event.
BTW, is the Recordsource so dependent on the OpenArgs that you need a dynamic recordsource?
Generally, if my recordsource is that dependent on run-time values, I build the SQL for the RecordSource before I open the form. Then I modify the SQL property of the Query that is the Reports RecordSource. Then open the report.
If I need to limit the report, I'll either write that directly into the SQL or use the WHERE argument of the OpenReport method.
Generally, if my recordsource is that dependent on run-time values, I build the SQL for the RecordSource before I open the form. Then I modify the SQL property of the Query that is the Reports RecordSource. Then open the report.
If I need to limit the report, I'll either write that directly into the SQL or use the WHERE argument of the OpenReport method.
ASKER
If I move the content of "Report_Open" (where I revise the Report's "RecordSource") to "Report_Load", I get VBA Run-time Error 2191 :
"You can't set the Record Source property in print preview or after printing has started."
"You can't set the Record Source property in print preview or after printing has started."
Good point, that is why I do it (revise the SQL of the RecordSource) in the code that calls the report, before opening the report or sending it to the printer.
ASKER
The strategy I am using is to allow the Access application at a single Till Point to be making more than one sale at the same time. All the items being sold in each of the selling sessions are stored in the same Table, but with their own "session number". When one of the sales is ready to be finalised and a receipt printed, I send in a "WHERE" clause in "OpenArgs" that is used to dynamically contruct the RecordSource, pulling out the required items from the shared Table.
In the past, when I have used an explicit "WHERE" condition, if there is a crash, the "WHERE" condition gets saved with the Report. I figured it was safer to dynamically construct the RecordSource each time.
In the past, when I have used an explicit "WHERE" condition, if there is a crash, the "WHERE" condition gets saved with the Report. I figured it was safer to dynamically construct the RecordSource each time.
As I said, I rarely see the need for dynamically setting a reports RecordSource. About the only time I ever do this is when I am creating a report based on a CrossTab query.
Otherwise, I set the reports recordsource and simply use the Where condition in the OpenReport method. If you leave this open a while, I'm sure some other experts will chime in with their recommendations as well. If not, click the "Request Assistance" button and ask the moderators to mark the question as neglected.
Otherwise, I set the reports recordsource and simply use the Where condition in the OpenReport method. If you leave this open a while, I'm sure some other experts will chime in with their recommendations as well. If not, click the "Request Assistance" button and ask the moderators to mark the question as neglected.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I eventually achieved the result I was seeking, after some experimentation of my own. Not sure if I fully understand what is going on, but it seems to work. See my final comment for a fuller description of what I did.
What does strLongOpenArgs look like?
What do your Report_Open and Report_Load events look like. Might be a way to recommend something other then the current method you are using to address the issues you are addressing in those events.