Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Truncating pdf
We regularly use oipi to send reports directly to pdf usually for attaching to an email.
We've recently had a customer bring to our attention that when they are sending a pdf with a batch of reports the pdf doesn't always contain the entire batch.
The simplest example is when emailing a customer an invoice. That works fine. Invoice prints direct to a pdf and attaches to the email. However, if they are running the same process but this time the pdf is to contain say 25 invoices, all 25 may or may not be included. The pdf seems to truncate at some arbitrary point. Maybe 10 invoices, maybe 12, maybe 21. The point is not consistent other than it is at the end of a completed invoice (which is effectively a print job).
I know that all invoices are being processed and sent to the printer, it just seems the pdf is terminating before it receives them all.
There is one set_printer("TERM") statement at the end of the batch job. That statement may take 30 seconds to execute and returns a successful status.
My guess is that the issue has something to do with printer spooling and the execution of the term just ends everything wherever the printer was up to. My problem is I don't know what to do to address that.
Any suggestions cause I've about exhausted my ideas and
We've recently had a customer bring to our attention that when they are sending a pdf with a batch of reports the pdf doesn't always contain the entire batch.
The simplest example is when emailing a customer an invoice. That works fine. Invoice prints direct to a pdf and attaches to the email. However, if they are running the same process but this time the pdf is to contain say 25 invoices, all 25 may or may not be included. The pdf seems to truncate at some arbitrary point. Maybe 10 invoices, maybe 12, maybe 21. The point is not consistent other than it is at the end of a completed invoice (which is effectively a print job).
I know that all invoices are being processed and sent to the printer, it just seems the pdf is terminating before it receives them all.
There is one set_printer("TERM") statement at the end of the batch job. That statement may take 30 seconds to execute and returns a successful status.
My guess is that the issue has something to do with printer spooling and the execution of the term just ends everything wherever the printer was up to. My problem is I don't know what to do to address that.
Any suggestions cause I've about exhausted my ideas and
Comments
It doesn't matter if we send the output directly to pdf via the export format in the INIT statement or if we print preview then use the export option on the preview screen.
Both methods exhibit the same symptoms
Offhand I concur that something just seems to give up and the output is no longer being captured. We have seen a similar problem when the output destination of for the PDF is being monitored by another process. In one case we recently dealt with, an FTP process was constantly waiting for the PDF file so it could send it elsewhere. Well, if the PDF output was big enough, the file was still being generated when the FTP process identified the file and moved it...thus truncating the PDF before it could be finished.
We worked around the problem by routing the PDF to a Windows temp folder first and then move the file to the final destination after it was done. Perhaps some kind of AV scan is interfering in a similar way.
So different workstations. different networks. different printers and therefore printer drivers.
Can confirm that it is just pages at the end rather than random missing pages.
But have another example where images were no longer being shown at some point in the report although the text was still output. That's more indicative of a memory issue.
Interesting that when you look in the local Windows Temp folder while the PDF is being generated, there is Pg(n).emf temporary file as it works on page n.
It's my recollection that you switch the content of the vsprinter record in sysenv between vsprinter and vsprinter2 or have I oversimplified?
If that is all you do then I was on classic and switching to vsprinter2 made no difference.
I used your sanity check and just got the same print preview as always.
How can I get it wrong?
So,
all invoices printed in the pdf.
But and there always is one....
nothing fits to the page now so in this example, forty odd invoices are spread over 88 pages.
Probably why we're still on classic oipi. Too much work to check all report fonts and alignments.
So this does narrow the field a bit. You might want to try printing to a PDF printer driver instead. This could end up being your workaround but at the very least it will absolutely point the finger at VSPDF.ocx if this method works...so this might also help you troubleshoot the problem also.