Thanks Michelle for the update. Interesting that EMPTYREPORT=OFF doesn't work with WHERE TOTAL. Seems like WebFOCUS is applying the EMPTYREPORT test at the wrong time in the process.

Sounds that way. I have submitted a case to IBI, so we'll see.

The official IBI answer is:................


********************** COMMENTS FROM INFORMATION BUILDERS **********************

Michelle,
Ok -- I see what you are referring to. That is correct behavior when using
WHERE TOTAL tests and we document it as such:

"If you have created a report that contains a WHERE TOTAL statement and the
test yields zero records, an empty report will display"


Thank You, B.J.

*****************************************

So I asked why.........

********************** COMMENTS FROM INFORMATION BUILDERS **********************

Michelle,
Because the WHERE TOTAL test is applied after record retreival, against
the internal matrix -- the EMPTYREPORT setting goes gainst the actual
record retreival.

That is the current behavior/limitation .

Thank You, B.J.

*****************

interesting...

quote:

interesting...

Indeed! Also interesting is the fact (unknown to me at that time) that EMPTYREPORT applies not only when producing "reports" as the setting name lead me to believe but to every TABLE FILE request in general.

See for instance:

SET EMPTYREPORT = ANSI

TABLE FILE CAR
PRINT CAR AND MODEL
WHERE COUNTRY EQ 'AUSTRALIA'
ON TABLE HOLD AS HCARS
END
-RUN
-IF &LINES GT 0 THEN GOTO :DO_RPT;
-TYPE No data.  Please check your selection criteria!
-EXIT

-:DO_RPT
-* Continue processing ...
-TYPE More stuff to do ...

I know there are no records for 'AUSTRALIA' in the CAR table so I expected to see the "No data..." message upon running the code above and nothing else, but no! I got "More stuff to do" instead.

When looking closely, I realized that by having EMPTYREPORT=ANSI, WebFOCUS creates a "dummy" record on the fly to satisfy the need of producing a complete report that includes no only HEADING and column titles, but also sub-headings, sub-totals, footings and the like -- well, that's it's intended purpose and is documented!

Little I knew that this behaviour was the same even when creating HOLD files. A closer look at the resulting feedback from WebFOCUS showed:

0 NUMBER OF RECORDS IN TABLE= 0 LINES = 1

So, I ended up with:
- A "dummy" record with MISSING values in the HOLD file
- &RECORDS=0 (as expected)
- &LINES=1 (unexpected to me then but not anymore!)

This is consistent in both 5.3.4 (yeah, I know) up to 7.7.03!

This may be documented somewhere but I've never seen it. I'm just trying to be more careful now and try to remember to always stick an "ON TABLE SET EMPTYREPORT OFF" in every request that will end up in a HOLD file, just in case EMPTYREPORT may have been changed in "hidden" places like server or user/group profiles.

Just a word of caution to those of us who usually check for &LINES to determine if we have enough results to proceed with extra processing ...