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.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
Hi, I want to specify some index fields.Some of my joins are taking a very long time to get the report output. Is it sufficient if I specify the parameter INDEX=I or FIELDTYPE =I in the master file?
There is something called "KEYS =0 " in the corresponding access file? What does this indicate? Is this the no of indexes?
One last question do we have to refresh the synonym or is it suficint thatwe add the extra line of code in the master and/or access file?
There is nothing in WebFOCUS to indicate an index for a relational table. The indexes are handled by the database and WebFOCUS doesn't need to know what is indexed. The KEYS parameter in the access file indicates the primary key in the table. So if the ACX file had KEYS=2, then the first 2 fields in the MAS would make up the primary key. The synonym most likely has nothing to do with your repsonse time. If your requests are running slow, there is some other reason. Most likely your request is inefficient. Put this code in your fex.
SET TRACEOFF=ALL SET TRACEUSER=ON SET TRACEON = STMTRACE//CLIENT SET TRACEON = SQLAGGR//CLIENT
This will send the SQL traces to the client. Add WHERE RECORDLIMIT EQ 1 since you only need to get the traces. Return the report in HTML format and view source on the page. You will see messages about optmization and the SQL that is being generated.
SET XRETRIEVAL = OFF is also a good way to get the trace code.
Try to only pass to SQL what SQL understands. There's an old post in Focal Point "WebFOCUS efficiencies against SQL tables". Basically, just get your data out of SQL using TABLEF and move all the fancy code to the HOLD file and response time will improve greatly!
Good luck!
Posts: 428 | Location: Springfield, MA | Registered: May 07, 2003
If your source table definition has changed, in any way, since the synonym was generated it is a good idea to regenerate it. If you have added keys or indexes since it was generated you should update it. This will ensure that the .mas and the .acx both reflect accurate information.
Indexes in the source table can help, but they must be applied to the source table and then re-gen your synonym.
As far as your code goes ... follow the basic rules of doing sorting and WHERE statements against database fields instead of DEFINEd fields. USe COMPUTEs instead of DEFINEs where ever possible. You automatically build efficiency into your request that way.
Posts: 346 | Location: Melbourne Australia | Registered: April 15, 2003