As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at email@example.com and provide your corporate email address, company, and name.
What's the source of your data? SQL Server, DB2, Oracle.....
Do you have JOINs, DEFEINs or COMPUTEs in your content?
If your data is in an RDBMS, I suggest you run with SQL Trace to see what kind of SQL your code is generating. Perhaps you can change things in the code that'll make your document run more efficiently.
WebFOCUS 8206, Unix, Windows
Posts: 1853 | Location: New York City | Registered: December 30, 2015
My Source is Oracle. I have some defines (just 4 or 5).
It's slow with interaction of the reports. And - and that's what bothers me, it's not fasten then when I create the exact same Report with the Oracle source. So no difference between hyperstage and no hyperstage..
Is there in General a mentionable difference between using hyperstage in normal reports and Dashboards and Portals (not only visualizations, cause there it is really an improvement) then not using hyperstage? Or is it really only useful in Connection with visualizations???
For large active reports, client-side performance will be mainly dependent on the amount of memory and the CPU speed of the system that the receiver of the report is using. I assume you can't very well tell your customers to plug in more memory...
Another issue may be network latency, especially on flaky wireless connections (for example in a factory full of big whirring machines causing interference).
You may be able to improve all these by reducing the amount of data you send to the report. Don't send unnecessary fields, keep your field sizes tight, use variable length fields (/AnV instead of /An), aggregate where you don't need details, etc.
Going further (and probably overboard), perhaps you can "pack" (parts of) your dataset for the report and have the report "unpack" it on the fly - but that will hit the CPUs on both ends of the line.
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :