> > IAC, I thought I had heard that doing a SET ORDER TO on a network

> > table

> > was slow or caused a performance hit, especially since all we want

> > to do

> > is use the index to check for the existence of a condition that could

> > nowadays be done with the SEEK(a,b,c) function. While refactoring,

> > should

> > this be done (...replacing the old SET ORDER plus SEEK command with

> > the SEEK function instead)?

> You should know the answer by now: test both versions under actual

> network conditions. There is a good chance that the current code is

> not noticeably slower than the proposed new code; if so, you've just

> saved a bunch of rewriting.

Generally, with many files(some big, some small), I've noticed

considerable 'scan' speed increases by removing any orders set on the

cursor with 'set order to'.

I personally doubt there would be a significant speed difference

between SEEK() and SET ORDER TO...SEEK itself, but if the ORDER is

left set on the file and subsequent record pointer changes are done,

it could slow things down-- but be very careful about removing the SET

ORDER TO's, as that order could be critical to the logic of the code

itself...

--

Derek