Hi All,

I have a fex which prints out the answers to survey across the questions summing the answers (since the underlying table structure has 1 row per students per question/answer pair) so that I have 1 row per student with all of the q/a in a matrix. Unfortunately, although the output comes out just fine and looking at the echo doesn't show any error the agent crashes. Have any one had this issue before? I'm using webfocus 767.


TABLE FILE ALLHLD
SUM
ANS
ACROSS GVBGSED_SDEF_SEQ_NUM
ACROSS QUEST AS ''
BY FULLNAME AS 'NAME'
BY FIDN AS 'FIDN'
BY COLL AS 'COLLEGE'
BY DEGC AS 'DEGREE'
BY MAJR AS 'MAJOR'
BY ATTR1
BY ATTR2
BY ATTR3
BY ATTR4
BY INT1
BY INT2
BY INT3
BY INT4
ON TABLE SET PAGE-NUM OFF
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT EXL2K
ON TABLE SET HTMLCSS ON
ON TABLE SET STYLE *
UNITS=IN,
SQUEEZE=ON,
ORIENTATION=PORTRAIT,
$
TYPE=REPORT,
GRID=OFF,
FONT='ARIAL',
SIZE=9,
TITLETEXT='&TERM.EVAL - &SURVY.EVAL',
$
TYPE=TITLE,
STYLE=BOLD,
$
TYPE=TABHEADING,
SIZE=12,
STYLE=BOLD,
$
TYPE=TABFOOTING,
SIZE=12,
STYLE=BOLD,
$
TYPE=HEADING,
SIZE=12,
STYLE=BOLD,
$
TYPE=FOOTING,
SIZE=12,
STYLE=BOLD,
$
TYPE=SUBHEAD,
SIZE=10,
STYLE=BOLD,
$
TYPE=SUBFOOT,
SIZE=10,
STYLE=BOLD,
$
TYPE=SUBTOTAL,
BACKCOLOR=RGB(210 210 210),
$
TYPE=ACROSSVALUE,
SIZE=9,
$
TYPE=ACROSSTITLE,
STYLE=BOLD,
$
TYPE=GRANDTOTAL,
BACKCOLOR=RGB(210 210 210),
STYLE=BOLD,
$
ENDSTYLE
END

Axion, if your excel comes out fine, how do you know its this agent that crashes?
i dont' see any code in this fex that writes anything identifiable to the agent directory that would prove that this fex is causing the crash..
How do you identify the agent with certainty, and what's in your agent when this fex finishes?

If you run this fex with html output, and eg a recordlimit, do you get the report? or do you get the crash message?

Hi Susannah,

In the webconsole the agent has my name on it and when I view the stats it says that the last masterfile name is ALLHLD. Then the agent state shows up as crashed. Could it be that some of the Questions are long?

Axion

Hi Susannah,

I neglected to include that running the report to html also resulted in the output displaying but the agent crashing. I placed a filter on the GVBGSED_SDEF_SEQ_NUM LT 60

on the table file that generates ALLHLD and the agent doesn't crash. Any value greater than 60 and it outputs but crashes the agent.

Thanks
axion

good research
so you probably have too many across fields.
you have 2 nested acrosses.
when the first is 61, you bomb.
There is a limit on the number of across columns, i don't know what it is, but there is a limit.
that' probably what's doing it.

Yeah,

According to the documentation I saw that an ACROSS supports up to 255 columns I'm no where near that. Mine are max 160.

But, I have noticed that for some reason WF doesn't like summing on alpha fields larger than ~2k characters. (I'm referring to the ANS field above. )

I decided to use exl2k and split up the report into chunks of 60 QA's per sheet.

This seems to alleviate the issue greatly but the 2k character limit above still presents an issue. Some of these answers are very wordy.

I'll have no choice but to chop it to 2k

What do you think?

There used to be an upper limit on the number of 'cells' in an across, and this was 256. So if you try to keep within this limit it may help.

This seems like a pretty significant limitation of the product. Are there any plans to increase or eliminate many of these seemingly unnecessary limitations?

The Across limit
32k length limit

and I'm sure other people know plenty of other similar in issues.

axion

What happens if you remove the Stylesheet, does it run to completion without crashing?

ON TABLE SET STYLE * ... ENDSTYLE

ACROSS involves buildng and populating an additional internal matrix: First an internal matrix is built and populated treating the ACROSS phrases as BY (and promoting them to th lead spot in the srt key). Then, in "post matrix processng", the number N of unique combinations of ACROSS valus is determined, and a new matrix is built, with the verb object fields each appearing N times. [See Cesare Petrizio's Summit presentation,Reporting Internals From a Reports Point of View: Part I and Part II]

That ACROSS matrix is (presumably) subject to the same size (=field offset) limits as a standard internal matrix. The effective size depends on the declared size of ANS, multiplied by N=160 or 200 or whatever the number of distinct ACROSS key combinations. 200 x 2000 = 200,000 bytes (plus the length of the BY sort fields) is a big chunk.

You could verify this by truncating ANS (in a DEFINE, not via reformattng in the TABLE request), doing a HOLD FORMAT FOCUS, adding CHECK FILE HOLD and ? FDT HOLD to compute the segment size. Reduce the field length to a point where the request behaves (e.g., A4); experiment with increasing it to discover the breaking point; and note the size stats for the largest handlable field size.


There was a feature introduced not long ago (who rembers the SET keyword?), to demote fields as needed, in a HOLD FORMAT FOCUS requst, to U-segments in order to circumvent the individual segment size limit (which is what induces the internal-matrix size limits). -- But I have my doubts whether that feature is applied to the repetitions of the verb objects in an ACROSS request, or to the "post" internal matrix of an ACROSS request. Besides, there's still a limit on the numbr of segments, which is reached pretty quickly when the field size is half a page.

hey,

I'm dealing with the same problem at the moment. A customer would like to have an excel-report with two sheets. one with comments and one with measures. since the commentsize is A1024 and they would like to have one year with 52 calendarweeks (ACROSS) I'm getting the same problem with the 32k masterfile size. I opened a case, since this is not the first time I'm reaching that limitation.

To give further readers another hint, I link the my last thead dealing with the masterfile size here