Does the elimination of items in the "Customize User Interactivity" items, AKA: Options available in the column titles, decrease the Limits of AHTML?

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

Doug,
ROWS X COLUMNS is the calc - Titles aren't the issue...
Tom

Morning Doug

Can you expound on what you mean by 'decrease the limits'? Are you wondering if AHTML loses some features? Or are you wondering if changing the titles mean the size limitations get smaller?

From the manaul, for what it's worth - Page 16 of Active tech manual for 8202:

Handling a Large Amount of Data
Because all post-retrieval processing is performed in the memory of the web browser, an active
report has a processing limit of approximately 5,000 records or 100 pages of output. The
active cache option enables you to send only the first page of active report output to the
browser and retrieve subsequent pages from a temporary cache on the Reporting Server. The
server also becomes the resource for performing all calculations, sorting, and filtering when
active cache is enabled. Since active cache uses on-demand paging functionality, WebFOCUS
Viewer is not supported.
Security Features

The active report with active cache option in the clustered server environment, using Cluster
Manager (CLM), will maintain the connection with the WebFOCUS Reporting Server on which
the temporary cache is created. This enables the retrieval of subsequent pages from the
browser, while the report is in the same browser session.
The active cache feature uses a POST instead of a GET in an HTTP request.

Anyway -thought that might help if you're thinking about speed of getting your first answer back on the browser. If you rely on the reporting server as described here, remember your user has to still be able to access the reporting server, so this route wouldn't be good if you mean to email the AHTML output to someone who is not connected to the WF environment.

Later!
Toby

Clarification: I want to know if it possible to increase the limits as mentioned on Page 16 of Active tech manual for 8202 (Number of rows that can be displayed in AHTML) by removing some of the Options available in the column titles, not the COLUMN TITLES them self, just the options that are available when clicking on the 'down arrow' to the right of the COLUMN TITLES.

Good question

Doug

Better open a case to get the answer to this one..

Thanks Chuck, I'll do that with a reference to this post and a note in the original post subject line.

Here's what I received from my case, Very Informative.

quote:

Probably the most important efficiency item you can do for Active report is, no NOPRINT fields.

Active reports are data, plus javascript. A lot of javascript. NOPRINT fields are just baggage. You can't see them, they just take up space. So, no dynamic reformat (like fieldname/A20) and no NOPRINT.

IE is the slowest browser, and 5K records is where it starts to get slow. A good running desktop (like an i7 intel) can handle more records (than an i3). So, the better the processor, the better the processing. We recommend 5K for IE because it is slow compared to Chrome, which can handle more records.

I suggest you benchmark how many records for you are fast enough. Please avoid NOPRINT fields. How you can do this is run your report with ON TABLE HOLD AS baseapp/filename. Then load that file with http:// : port/approot/baseapp/hold.html. And, look at the size of the report in baseapp. It will become exponentially larger based on the number of records, then eventually the performance will decline.

Plus, it also matters how wide your active report is. We make javascript for all the data, so it can be dynamically reformatted. The larger the report, the larger the javascript. For IE, we suggest 5K records (probably based on 20 columns). For Chrome, up to 20K records can be ok. Possibly you can find some inbetween size that is acceptable for both.

Does this provide some insight?