>>Edward,
>>
>>>If I will tell you what I really think about SET RELATION, I wonder that you take it as personal offense, so I would just stay within well-known fact that SET RELATION just mask on SEEK() behind the scene, so it cannot be faster.
>>
>
>Try this code fragment and you be able to verify that SET RELATION
>is indeed faster. When opening the data each time the results on
>my P-400 running NT 4.0 were as follows:
>
>SET RELATION - .094 (faster)
>SEEK - .110
>
>without opening the data tables
>
>SET RELATION - .062 (about twice as fast!)
>SEEK - .125
>
>notice that i ran the set relation first to give the seek
>routine an advantage of priming the index tags...
>
>The proof is in the benchmark.
>
>*!* clos data all
>*!* clea all
>*!* clear
>
>*!* open database tastrade
>*!* use orders in 0 order order_id shared
>*!* sele 0
>*!* use order_line_items
>
>lncnt = 0
>lnst = seco()
>set rela to order_id into orders
>SCAN
> IF NOT EOF('orders')
> lncnt = lncnt + 1
> ENDIF
>ENDSCAN
>
>@ 1,1 say 'SET RELATION Results:'
>@ 2,1 say lncnt
>@ 3,1 say seco() - lnst
>
>
>lncnt = 0
>lnst = seco()
>scan
> if seek(order_id,'orders')
> lncnt = lncnt + 1
> endif
>endscan
>@ 6,1 SAY 'SEEK results:'
>@ 7,1 say lncnt
>@ 8,1 say seco() - lnst

Tom,

It seems to me that this post was response to me (not to Walter), so I feel obliged to give your some ideas. You probably missed my point (at the start of this thread) that SEEK() approach is faster because you will fire it when it's really needed, and SET RELATION will fire anyway, i.e. there is difference between blind speed and application speed. The latter one is always concretic, SEEK() makes the process of moving pointers better controllable, so it will allow to implement more flexible solution. Just to illustrate why SEEK() might be faster I want to give you following oversimplified example. Lat say, each record of master table bears UserId to identify user who entered this record to the system first time. You will use this foreign key to run some statistic reports, but you're not going to bring it to data entry screen(s). However, if you set relations you will still fire redundant implicit seek. I understand, you may answer here that you can realign SET RELATION for each particular case, but I hope you see the point.
Ultimately, it's uncommon in real application to run SCAN on whole table, right? Instead of this you jump from one record to another (SEEK and not SCAN), i.e. fair test (which would have some sense:) is to compare SET RELATION against SEEK for one-record-jump, but I believe nobody is going to investigate the result of such benching.