Re: Printer Problem

["Corey" <corey@spectrumsoftware.net>]

    I don't think holding the database open in a transaction while a print
    job is in progress is such a good idea. There are lots of reasons why
    the print job "Thread" may never finish and you'll be left with a transaction
    hanging the database. Better to do a two-phase operation. In the first
    phase you can update the database to indicate that the print transaction
    has been started and in the second transaction (started when the print
    job finishes) you can update the database to indicate whether the job
    was successful. And successful may only mean that the printing thread
    was able to deliver the content to the print sub-system and nothing 
    more.

    If you really are printing checks, you may need a third phase where a 
    person actually checks the details of the printed check to verify that
    it is correct and then finally update the database to indicate a positive
    printing success.

    --Corey
______________________________________________________
William C. Brown
Chief Architect. Spectrum Software Inc.

11445 Johns Creek Pkwy
Duluth, GA. 30097.
Suite 300.
Tel > 770.813.4952
e   > corey@spectrumsoftware.net
web > www.spectrumscm.com

----- Original Message ----- 
From: "Kevin Chipalowsky" <kchipalowsky@yahoo.com>
To: "Lynn Young" <yconsis2003@yahoo.com>; <ajug-members@ajug.org>
Sent: Thursday, March 06, 2003 8:39 AM
Subject: Re: Printer Problem


> Lynn,
> 
> Unfortunately, I don't think there is an easy solution
> to this problem.
> 
> Printing is a complex process on most systems that
> involves multiple layers of buffering.  For example:
>  + if Windows crashes in the middle of a print job,
>    it will reprint the document next time it reboots.
>  + Some laser printers are smart enough to reprint a
>    document if they detect a paper jam half way
>    through printing a page.
>  + Some really expensive printer-photocopier devices
>    will buffer documents, and hold them until an
>    operator enters a passcode on the device to
>    "release" the document for printing.
> 
> This is a tough environment.  If you're trying to
> write software that guarantees a check is never
> printed more than once, you're fighting an uphill
> battle.  I think the best you can do, is guarantee
> that a check is never given to the operating system
> more than once.
> 
> Because you can't rollback a print job, I think your
> transaction will need to be structured as follows:
> 
> First, update the database.
> Second, try to print.
> If you catch an exception or printing otherwise fails,
> rollback the database transaction.
> 
> From there, let the operating system do its best to
> make sure the document is printed.  Your biggest
> concern is that some system down the line decides that
> the check needs to be printed twice.  If anyone knows
> how to get around this, I'd like to know too!
> 
> Kevin
> 
> 
> 
> 
> 
> --- Lynn Young <yconsis2003@yahoo.com> wrote:
> > 
> > Hello, all
> > 
> > I am a new one here and I have a question to ask. 
> > If in a java application, I want to print things
> > like checks or other SEQUENTIAL documents.  I set up
> > an initial number in the database, say 1000, and
> > each time I print, I increase the number by 1, so
> > next time it'll start with 1001, and so on...  My
> > question is: do I have a way to check whether THIS
> > one has been printed, only when it is printed, then
> > I need to increase the number.  Since printing and
> > updating database are two different process, one
> > could fail and the other one may still go on.
> > 
> > Thanks in advance for any suggestions.
> > 
> > Lynn
> > 
> > 
> > 
> > ---------------------------------
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, and
> more
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 
>