Hi Nadya,

>I answered you once, but unfortunately lost the connection :(
>Briefly, I ran few tests on my local machine (through the network) using your, Trey's and David's idea.
>Table1 ~ 400000rec, Table2 ~300000rec.
>Trey's idea - 68s.
>Your Indexseek (should be !indexseek, BTW) - 76sec with set deleted on and 69sec. with set deleted off.

Hmmm. very strange.... but wait, I might have been confusing IndexSeek with the KEYMATCH function. Just try:

SCAN FOR !KEYMATCH(ProgID,nYourTagNo,"Table2")

Please, let me know the results.

Walter,





>David's SQL - very strange thing - first time I ran it, it ran quite fast, but then I decided to repeat tests and measure the speed, they extremelly slow, so I killed VFP each time...
>
>>Nadya,
>>
>>Did you try all experiments on a network ? The solution with INDEXSEEK should be faster...., at least in theory... One trap you easely fall into is that VFP and the OS buffer large protions of tables and indexes. Testing on a workstation somewhere on a network provides more reliable results. It maybe wise to test in an environment that is the closest to the environment of production.
>>
>>Walter,
>>
>>>Hi Trey,
>>>
>>>Your idea seems to be the fastest method. I tried Walter's idea - the result is almost the same. David's SQL ran very quickly the first time, but all my other experiments with the same SQL were so slow, that I didn't wait the finish of SQL. I tried on the smallest ~400000 rec. in child and ~300000rec. in parent. Took 68 s.
>>>
>>>Thanks.