>>>>>>>I want to maximize the speed of performing calculations in related tables. I will be performing a REPLACE on every record in the child table based on values in the Parent record. Any thoughts on the best performers ?
>>>>>>>
>>>>>>>1) Using Set Relation to 'automate' finding records in child tables
>>>>>>>
>>>>>>>2) Using Set Filter to 'manually' SKIP thru records in child tables based on Parent key.
>>>>>>>
>>>>>>>3) Using Scan For in child table based on Parent key.
>>>>>>>
>>>>>>>4) Using good old fashion Seek in the Child table based on Parent key.
>>>>>>
>>>>>>Peter;
>>>>>>Try to stay away from FILTER as much as possible. In dealing with child records, I usually use the SELECT command and include RECNO() as a column. Then use the record number to point directly to the record in the child table.
>>>>>>
>>>>>Oh I like this myself!
>>>>>SELECT RECNO() AS myfield
>>>>>
>>>>>Is that what you mean Kia? That's an interesting approach I have never considered before.
>>>>
>>>>Yes Roxanne, but I'd include the aliase when calling RECNO() such as
>>>>
>>>>SELECT RECNO('child')
>>>>
>>>>This has worked for me reliably in FP 2.6 and haven't personaly seen problems with VFP.
>>>
>>>The fact you had no problems with it is just a happening (ie: you were lucky!). Generally, is not good to use RECNO() inside a SELECT SQL. To use it with a parameter: You base your program on your luck and cross your fingers! :)
>>>
>>>Vlad
>>
>>Paul;
>>I tested using RECNO() in the SELECT commend in FP 2.6 extensively and found it be reliable. Since I haven't run any tests using it in VFP, I personally don't know of the level of it's reliability. However after reading the threads regarding this issue, I will think twice before using RECNO() in VFP. But I like to emphasis that my code was well tested and proved to be reliable not by luck, or keeping my fingers crossed.
>
>All that I said about RECNO() it's true in FP 2.6 as well as in VFP. Please read my reply (yesterday) to Jim Nelson. I don't wanna say that you haven't tested your app. You may be in a case where this works. But the fact that it works in your case doesn't mean at all that it's reliable (at least, not in my definition for "reliable"). I also can write a program where RECNO() will work 100% in a SELECT-SQL. But there are so many assumptions I must make (or code to write, comments, doc, etc) that I consider it doesn't worth the trade. I never take useless risks in my programs.
>
>I didn't want to be rude yesterday and I don't want to be now. So, please forget me if...
>
>I just wanted to make you very careful on it. Also, I am not the only one to say that RECNO() is not good in SELECT-SQL.
>
>If my yesterday examples didn't convince you, here's another case from a real system I worked for:
>
>SELECT EmpID, RECNO() FROM EMPLOYEE INTO CURSOR History
>
>This SELECT is perfectly reliable and it cannot be broken very easy. Unless you have a programmer who's used to use the alias as parameter for RECNO() (This is a good practice, isn't it?). Only that in this case, if he modifies the code to look like this:
>
>SELECT EmpID, RECNO("EMPLOYEE") FROM EMPLOYEE INTO CURSOR History
>
>it will brake your program. This will happen only because that programmer is not aware about this problem. Can you blame him? No, because this is not documented and it's supposed to work (at least in my opinion). I must say here that I was the one who broke this code :) because I had to enhance that module, so I've added another table to the SELECT another table, I've put the alias into RECNO() (you know, just to be sure!:))... My luck was that I tested it right away and it didn't work. :)
>
>If you're still not conviced, I can give other examples also.
>
>Once again: I agree that your program might be correct and reliable and pass all your tests. But it's still risky code because it's so easy to be broken in a future version by a modification you (or somebody else) will do in maybe a total different place... it just doesn't worth it. At least, put a comment before your SELECT to remind how the code can be broken! :)
>
>Vlad

Just a note: microsoft says that a recno() might work on
select - sql statements but they are not supported in any way
and may or may not work in the furture. So it is a use at your
own risk command. So most programmers tend not to use them
for compatiblty reasons.

P.S.> the fastest way I found on replacing a field like this is:
OPEN TABLE ONE ORDER 'UNIQUE TAG' IN 0
OPEN TABLE TWO IN 0
SET RELATION TO 'UNIQUE TAG' INTO ONE
REPLACE ALL ONE.FIELD WITH 'SOMETHING'