>> Stop thinking tables, start thinking datasets!
>>
>> Indexes are useful in WHERE and JOIN clauses, selects that return entire tables normally don't
>> benefit much from using an index (it might be a bit quicker or slower, but the difference isn't huge).

>In this case I need to traverse the whole table - and I join to a couple of others for lookup values.
>It is not for display, and there are a few WHERE clauses in the final query. The real query takes over
>7 minutes..which is totally unacceptable. I pared it right down to see if the non indexed read is the
>problem. As far as I can see, the indexes are not being used.
>
>When I do a join on another table - THAT table also reads in in non indexed as well (even though there
>are indexes on the join fields). Same problem, I am thinking.
>
>I do not care about the ORDER BY - I don't care about the order the records are processed in. I simply
>use it to try and force the use of an index. It did not work in this case, but I seem to recall it
>working in other cases.

Good to hear that my suspicions were wrong. The query you showed us should take a few seconds and absolutely not 7 minutes (unless we're talking huge blobs), show us the real query (with the plan and some information about the selectivity of indexes) and we'll see whether we can spot anything.

Set