appServer problem

I've been using PDF include for many years but have recently tried to deploy it running under an appServer agent. I've isolated the problem to the pdf_load_external procedure. A symptom of the problem is that when this code is run:

/* If we can put the data into a Character Field then do so.
Then change any Xobject references within the external file. This is
due to duplication of Object names when using multiple external PDF
files */

ASSIGN iFileSize = GET-SIZE(mFile)
iPointer = 1
iMemSize = 10000.

iFileSize is unknown (?) rather than an integer > 0. I have processed the same procedure in a client session rather than an appServer session and the iFileSize was 125 in one loop and 140 in another.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hi Sam May be a regression

Hi Sam
May be a regression has been introduced at one point for appserver.
If you add the following code after FILE-INFO:FILE-NAME = ... :

FILE-INFO:FILE-NAME = TT_pdf_external.ext_file.
/* 23-JAN-2011 jcc: check that the file exists, else it could crash the whole session */
IF FILE-INFO:FULL-PATHNAME = ? THEN DO:
RUN pdf_error(pdfStream,"pdf_load_external","Cannot find external file " + QUOTER(TT_pdf_external.ext_file) + " !").
NEXT.
END.

what does it do? If pdfextract.p did not create a file (other problem to investigate) then at least it won't go further...

TIA

JC


appServer Problem

JC,

I took one more shot at determining the problem and ended up learning that it was something foolish on my part. The problem isn't the appServer, but the machine on which it is running. PDF include itself is loaded into libraries for use by the appServer agents but the zlib1.dll was never installed on the server. After the installation everything is fine.

Thanks for your comment.
Sam


cool

Ok, nice to know this is not a pdfinclude problem ;) and that it works for you! we can close the subject then.


Subject close

That works for me.