I get above error when I output my report as PDF, but not if I output it as HTML or EXL2K - go figure...

Any idea how to figure out what's causing this issue?

The report isn't particularly big, it's probably caused by something in the (rather gimmicky) layout. Removing the styling didn't help though.

This message has been edited. Last edited by: Wep5622,

Perhaps there's another message accompanying this one, view source in the HTML version and look for other "(FOC" errors...

I double and triple-checked - no errors in the HTML source.

The problem only snuck in after optimizing some of the code, but I don't remember what I changed exactly. Unfortunately, at that point I hadn't added it to our version control software yet, so I can't trace back what change broke it :/

It's probably not the amount of data (TABLE=76 LINES=60), but much more likely something in the way the data is laid out (some MacGuyvering going on in this report).

I'll try disabling parts of the code some more to see if I can find the culprit, but it only occurring with PDF output limits my options a bit...

I did find some concatenated fields that didn't fit in the result field (no error or warning), which possibly caused some memory allocation errors and a subsequent crash of the involved application. Fixing that got me a bit further.

However, now I got stuck on a field that's used in the report straight from the data-source, with no alterations. It's an A1950V type field, and it's crashing the PDF's... There's a style for that column to wrap it in 17cm, but enabling/disabling that isn't helping (in fact, enabling that style with the field disabled causes a crash as well).

It would seem the code for generating PDFs in WebFOCUS is rather fragile.

Wrapping NOPRINT fields and content going over the page boundaries seem to cause problems too.

It's working now, but that required baby steps to get from one minimalist working state to the next. Holy cow!

Admin killed your agent.

- ABT

When it suddently started happening to us, we realized that it occurs in PDF when the report is too wide. It used to yield page 1.2 etc. Now we get the server error. Sometimes SET ERROROUT=OFF helps. Most of the time we WRAP the longer txt fields in the output. That takes care of it.

quote:

Originally posted by ABT:
Admin killed your agent.
- ABT

I did no such thing!

This is a development box with a local WF installation, so there are no admins secretly killing my reports in the background. It is possible that Windoze killed the process for some reason, but it seems more likely that the process just crashed. There wasn't enough load on the system to warrant the OS shooting processes down (if Windoze can even do that).

After all, the content was going over the page edge, was trying to wrap non-printed fields and did assign more data to some fields than would fit in them. An access violation or a segmentation fault or something of the kind seems quite likely in such scenario's. That does indicate a bug in WF though, even though you need to write faulty code to trigger it.