> > 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 _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
