>>OK views make sense for single tables in cases when I cannot find a simple set key version:)
>>Cetin
>
>I think you can ALWAYS create an index for a SET KEY TO. The problem is in the sorting. You need different indices for different sort orders (I am thinking about indices with a concatenated expression - the first part would be used to replace a filter; the remainder would control the viewing order). I don't think this would be efficient or practical:
>
>The framework I use creates indices "on-the-fly" when a user double-clicks on a column header. It will even sort on multiple columns (for this, the user Ctrl-clicks on the second, third, etc. column). This definitely requires temporary indices. All this works much faster on a view. As an example, the subset of 100 records I am looking at are indexed quickly with a view. With a filter - or SET KEY - all 60,000 records would have to be indexed.
>
>Hilmar.

Hilmar,
Sometimes I can't create an index for set key to (composite keys). ie: Id and state. I want to set range where Id is between 100 and 103 and state between 'M' and 'P'.
(I could simulate a view by creating temp indices on the fly with for clause and benefit set key. Would still be faster than a view - but feasibility changes per real data and usage).
OTOH yes 60000 should be indexed but table indexes are permanent compared to temp ones and they update per change. I would prefer 10000K recs table and set key to if I could do it vs a view that returns say 100K recs (creating temp indexes would consume time).

Cetin