>Hi all.
>
>I'm wondering if you'd consider this an architectural issue or something else. Please tell me what you'd call it.
>
>I found a piece of code in an otherwise multi-user environment that builds a .IDX on a shared file. The IDX was filtered and used to access a subset of 5 million records. It took several minutes to build, but the users didn't mind that.
>
>I tripped over this issue while debugging. I only needed to change the code to SET FILTER using existing keys instead of INDEX ON to get the same effect in seconds.

Fifteen years ago I did great with temp indexes - in mFoxPlus and FP1.0x. That was the poor man's SQL of the time. I even had over-the-shoulder indexes, i.e. indexing on a field in a related table plus a field in the current table. This was for reporting only, and I took care to kill the temporary idx afterwards, and to give it a nonconflicting name (probably went to a local temp directory, don't really remember).

But all that was gone when I laid my hands on 2.0 and the internal SQL syntax. All the reporting code where I used temp indexes just shrank by 60%.

So... maybe you have a case of a predecessor who just likes to do it the way it was once done?