• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 642
  • Last Modified:

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.
0
colinasad
Asked:
colinasad
  • 5
  • 5
1 Solution
 
Dale FyeCommented:
Well, the normal method would be to replace "acViewPreview" with "acViewNormal".

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.
0
 
colinasadAuthor Commented:
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).ControlName" type of expression in the Report.
(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).ControlName" expressions do not work properly when the printout is actually generated.

Hope that sheds some more light on what I am trying to do.
0
 
Dale FyeCommented:
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.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
Dale FyeCommented:
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.
0
 
colinasadAuthor Commented:
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."
0
 
Dale FyeCommented:
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.
0
 
colinasadAuthor Commented:
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.
0
 
Dale FyeCommented:
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.
0
 
colinasadAuthor Commented:
After a bit more experimentation I have managed to achieve the effect I am after.

Using some tracer messages, I seem to have discovered the following :

The Report_Open and Report_Load sub procedures both appear to get executed properly when the Report is opened with acView = acViewPreview.

With acView = acViewNormal, Report_Open seems to be executed, but not Report_Load.
Even when I moved the VBA code from Report_Load into Report_Open, that code did not seem to get executed and the Report did not print at all.
When I moved my Report_Load VBA code into the ReportHeader_Format sub procedure, it seemed to get executed OK and the Report was printed.

I don't really understand why Report_Load should not be invoked when acView = acViewNormal.

The other change I have made to my instructions in my original posting is that I only use the first DoCmd.OpenReport and final DoCmd.Close lines, removing the 3 lines in between.
0
 
colinasadAuthor Commented:
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.
0

Featured Post

Free Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now