>>>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.

Edward,
I've read through this entire thread as it's been posted and I think you hit the nail on the head with this last one. The question of which is faster SEEK or SET RELATION isn't meaninful. The two commands/methods serve different purposes. Since there is an implicit SEEK when a relation is set and the record pointer in the master (related from) table is moved the underlying mechanics are the same. The question is how often the record pointer in the master table will move. If the answer is either often or for every record in it then clearly SET RELATION and SCAN/ENDSCAN will save numerous command executions over a SEEK times the number of records in the master table. IMHO, asking which is faster SEEK or SET RELATION is the same as asking which is faster SCAN/ENDSCAN (or the dreaded DO WHILE NOT EOF()/ENDDO) or issuing a skip for each record in the master table. SCAN/ENDSCAN is not only faster it's better programming by using the tools included in Xbase.
Thanks for listening.
-Dore