Im a newbie to Access but I can imagine a situation in which reports sent 
to the printer fail to print properly dispite safe guards of out of paper 
type errors etc.  I concede that it's a rare occurrence.

I need to understand how best to structure a function that sends the 
reports to the printer and updates a "printed" flag in the table following 
a messagebox response confirming the reports printed okay - and/or (in the 
event I am not "happy" with the printed output) captures the records that 
constituted the report and "holds," "stores" or "identifies" these records 
for a reprint command (without setting the "Printed" flag in the table) 
for a later time when printer problems have been attended to.

The query is set to run the query once a week when the machine is switched 
on.  It sets a text-type flag on the form and waits for a preview and/or 
print command and then waits for confirmation by way of the messagebox 
acceptable printing

The query looks at the tables to find records that satisfy a narrow time 
band (between 80 -85 days earlier than now()) criteria.  If the record is 
not flagged as "printed" data would be "missed" by the query on its next 
pass 7 days later unless some other field or table can capture whether the 
record has generated the report.

Sorry the explanation is so drawn out
Appreciate any help
Regards
Kevin

Hi Kevin,

Your query:

I need to understand how best to structure a function that sends the
reports to the printer and updates a "printed" flag in the table following
a messagebox response confirming the reports printed okay - and/or (in the
event I am not "happy" with the printed output) captures the records that
constituted the report and "holds," "stores" or "identifies" these records
for a reprint command (without setting the "Printed" flag in the table)
for a later time when printer problems have been attended to.



I have come to the conclusion that just using a 'printed' flag is limiting
(presumably a Yes/No type flag?) - how can you re-print all of a given
day's output if it is lost or incorrect?

These days I do not use a 'printed' flag but use a 'printed_date' field - I
populate this with the current date when printed and then can then print a
given day if so required.

From your description of your system I gather that you print the reports,
wait for a user confirmation that all is OK and flag the batch as
'printed'. You are left with 3 possibilities:

   whole batch faulty - needs reprint - you can do this easily if you have
   NOT set the flag, but, if the flag has been set in error, you have a
   problem. With a data not a flag, you can have a variant of your report
   that will ask for a given date and re-print all those records with the
   date.

   all OK - no problem

   Some OK and some not - this is the messiest situation - why not have a
   holding table (a table that is emptied just before day's print run) to
   hold sufficient data to identify the records printed PLUS a re-print
   flag? This would allow the user to go into a form showing the
   identifying data and flag those that need re-printing.

   The process would go like this:

   at start of day, empty out the holding table

   do the report run

   add the identifying data to the holding table with the re-print flag set
   as default of NO

   user checks output

   if output ALL ok, hit a button to run a process which sets the
   'printed_date' to current data for all records in the holding table

   if output ALL faulty, do whatever is required to resolve and hit a
   button to run the report sequence again

   if output PARTLY faulty, user opens print confirmation form based on
   holding table and selects the re-print flag for the faulty records (i.e.
   sets to YES) - then do whatever is required to resolve and hit a button
   to run the report sequence again for the records with re-print set to
   YES

   go through the loop again until all is OK and follow the process
   outlined above for a complete success



I appreciate that this is a simplification but as a process it would work -
is this the sort of thing that would work in your situation?










*************************************************************************

This e-mail may contain confidential information or be privileged. It is intended to be read and used only by the named
recipient(s). If you are not the intended recipient(s) please notify us immediately so that we can make arrangements for its return:
you should not disclose the contents of this e-mail to any other person, or take any copies. Unless stated otherwise by an
authorised individual, nothing contained in this e-mail is intended to create binding legal obligations between us and opinions
expressed are those of the individual author.

The CIS marketing group, which is regulated for Investment Business by the Financial Services Authority, includes:
Co-operative Insurance Society Limited Registered in England number 3615R - for life assurance and pensions
CIS Unit Managers Limited Registered in England and Wales number 2369965  - for unit trusts and PEPs
CIS Policyholder Services Limited Registered in England and Wales number 3390839 - for ISAs and investment products bearing the CIS
name
Registered offices: Miller Street, Manchester M60 0AL   Telephone  0161-832-8686   Internet  http://www.cis.co.uk   E-mail
cis@c...

CIS Deposit and Instant Access Savings Accounts are held with The Co-operative Bank p.l.c., registered in England and Wales number
990937, P.O. Box 101, 1 Balloon Street, Manchester M60 4EP, and administered by CIS Policyholder Services Limited as agent of the
Bank.

CIS is a member of the General Insurance Standards Council

CIS & the CIS logo (R) Co-operative Insurance Society Limited

********************************************************************************