>>>>I see from later dialogue that you are ready to accept this as 'normal'.
>>>>I would say that you should be able to get better myself, and by much too.
>>>>Does a BROWSE take as long when you have set the index to bed and opened the BROWSE with the Key option (for your example below)?
>>>>I suppose that RAM could be implicated here -large indices may not be able to be efficiently loaded?
>>>
>>>The browse take 6 to 7 seconds (even with the method above). I have 64megs of RAM on a PII.
>>>
>>>Interesting note is that if I set a relation between this large table and a parent table and then choose record in the parent table... the child records are displayed instantaneously. This means that relations between tables are implemented are a more fundamental level than a SQL statement. Perhaps I can harness this concept in my query...
>>
>>Have you considered file fragmentation?
>
>Is this an issue on a Netware 4 server? I thought the thing defraged itself.
>

Just as much as NT defrags itself - it uses a better mechanism to manage the disk cluster addressing than DOS/Win does with FAT, but fragmentation does occur, and short of cleaning up the disk space and rewriting the files, there doesn't seem to be a great deal you can do to avoid it unless the files is written in a single swipe.

>P.S. I reindexed the table (takes 1/2 hour). The query is now down to 3 seconds. This is getting into the acceptable range.

Index and memo bloat is a different issue than disk fragmentation - recreating an index from scratch reduces the size of the index file by eliminating unreclaimable portiosn of the index space, and writes sections of the index so that the time to access within the index is minimized. Waste space occurs in memor files as well, since rewriting a memo field often leaves unreferenced space in the memo field that's only recovered by packing or copying the memo file.