C
Chris Kees
I have a deployed application that prepares data in Access
and sends it to Word, where it is merged and printed to a
network printer. Nearly every step of the process is
directed by the Access VBA code (implemented through code
within buttons on one or more forms), including saving the
previous printer and tray settings of Word so they can be
restored after the application has finished its work.
The networked printer was recently converted from a
Novell "print managed queue" to IP printing, and now the
printer is producing intermittent, and in many cases, non-
reproducible, errors, such as ceasing to print in the
middle of a "batch" of documents long after the
application (both Access and Word) has finished its work
and marked the data as processed. Since this means the
work has to be re-processed, my users are exhibiting signs
of frustration and discontent.
Today, the main printing process completed all its tasks,
batching the items, releasing them to Word, saving the
printer settings, telling Word to print, resetting the
printer settings, and marking the inventory as printed.
The network printer monitors then reported that roughly
40% of the documents were printed, and we needed to
reproduce the rest. When the reprint module was invoked,
then a processing error arose at the instruction where the
printer settings were being set to the application's needs
by Access just before the print command was sent.
When I ran the application task from my developer's
workstation, the error was not encountered. I then had
the developer's edition installed on the user's
workstation so I could debug the problem. When I stepped
through the code at the workstation, the application did
not raise the error again.
There was some conjecture that the "printer name" being
sent by Access to Word was not a valid value, but the same
string has already been previously used during the normal
processing run earlier in the day. (I am reluctant to
change its value for fear that the main printing process
will start encountering errors.)
Any thoughts, perspectives or insights will be appreciated.
Chris Kees
and sends it to Word, where it is merged and printed to a
network printer. Nearly every step of the process is
directed by the Access VBA code (implemented through code
within buttons on one or more forms), including saving the
previous printer and tray settings of Word so they can be
restored after the application has finished its work.
The networked printer was recently converted from a
Novell "print managed queue" to IP printing, and now the
printer is producing intermittent, and in many cases, non-
reproducible, errors, such as ceasing to print in the
middle of a "batch" of documents long after the
application (both Access and Word) has finished its work
and marked the data as processed. Since this means the
work has to be re-processed, my users are exhibiting signs
of frustration and discontent.
Today, the main printing process completed all its tasks,
batching the items, releasing them to Word, saving the
printer settings, telling Word to print, resetting the
printer settings, and marking the inventory as printed.
The network printer monitors then reported that roughly
40% of the documents were printed, and we needed to
reproduce the rest. When the reprint module was invoked,
then a processing error arose at the instruction where the
printer settings were being set to the application's needs
by Access just before the print command was sent.
When I ran the application task from my developer's
workstation, the error was not encountered. I then had
the developer's edition installed on the user's
workstation so I could debug the problem. When I stepped
through the code at the workstation, the application did
not raise the error again.
There was some conjecture that the "printer name" being
sent by Access to Word was not a valid value, but the same
string has already been previously used during the normal
processing run earlier in the day. (I am reluctant to
change its value for fear that the main printing process
will start encountering errors.)
Any thoughts, perspectives or insights will be appreciated.
Chris Kees