Posted by Tom Fulton on November 11, 2005 at 12:53:04:
We have switched over our DocumentImaging system from being and ODBC-driven system ( MySQL database with various tables allowing documents to be "reassembled" in HTML ) to a PDF-driven system. Our
first installation has this setup installed. We use PDFFactory. As an example, our invoice print program does a first pass to print hard copies for mailing, then performs a second pass to the PDF printer with a (Document=...) mnemonic using a filename that includes
our unique invoice number.
Here's our problem: The end-user faxed us up a document where it was supposed to be a Notification document from today's run, but our
file actually had the PDF image of a Notificatn printed four days ago! The filename had the correct order number, the PDF was from a different order run four days ago.
Here's my suspicion: The Comet-generated filename of ObjectProgram+
'@20@' + (Term$) + [RandomNumber] is eventually generating numbers that match files already in the AutoSave folder. If, as I suspect, PDFFactory is seeing the existing file and simply dropping the new file and using the old file, then we'd get exactly the scenario that
we are encountering.
Solutions: I know that this filename arrangement originally came from files going out to Comet Document Manager. For the PDF printing
to work in our DocumentImaging system, we need to be able to insure that the filename being AutoSaved is unique. I don't know whether this is an issue to be addressed with Signature or with PDFFactory.
I have a question in to PDFFactory concerning what happens if the
"Save as unique filename" checkbox is turned off ( on is default ). If they overwrite when it is off, then I'm good to go. If not, hmmm.