Hi, Nadya - long time no C... er, Fox :)

>>I always filter on the same (logical) field, which is indexed. Since this is a single-user application, and filtering would have to go through the whole table anyway, this way I at least do it in only one pass:
>>

set filter to
>>blank all field lIsInFilter
>>replace all lIsInFilter with eval(cFilterExpr)
>>set filter to lIsInFilter

>>This way, I still get the usual delay while applying a filter, but after that the navigation is nearly instantaneous, and I know my filter is optimized.
>
>In our case there is a 1 char field, which is a status field. Of course, there is an index on this field. Each user works with his (her) own work file, but there is just one table, which expands status into its description (and there is a relation set from the work table to this 'description' table), and this table is used by all users. If this is the root of the problem, this application can be changed by creating a form's array in Init and then using this array instead of the table...
>
>Currently I'm working on documentation for the old projects of mine. I may play with this idea, when I would be working on this particular project.

I was doing that too many times, when I knew I had a small table which I will need in a few combos - even had a combo which had such an array property so it kept it to iteself (and closed the original table immediately after its init). The difference is that I did this right away. Doing it long after most of the code is in place... I'd think twice.

It may be even simpler to have a readwrite indexed cursor pulled from that lookup table, and then just close the original lookup table. You can even do some adjustment of the aliases (use the original table under a false alias, and use the real alias for your cursor). In that case, you don't have to touch the code at all, just do this when you open that table. This can be done and tested in 15 minutes.

p.s. Keep your spirits high - jobs can be found here. I've proven it several times.