Focal Point
specifying indexex for table

This topic can be found at:
https://forums.informationbuilders.com/eve/forums/a/tpc/f/7971057331/m/5791008331

November 01, 2004, 11:37 AM
<Kalyan>
specifying indexex for table
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?

Thanks in advance
Kalyan.
November 01, 2004, 12:12 PM
<WFUser>
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.

Hope this helps.
November 01, 2004, 02:28 PM
Carol Dobson
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!
November 01, 2004, 09:59 PM
Piipster
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.