I would say: especially if the alias is specified. The same goes for other functions, but RECNO() and DELETED() are the most important since it's very tempting to use them in SELECT-SQLs.

Specifications? :) What, where? :) Just joking! I know you're very upset because of VFP docs and I don't want to start another long thread on this. I would say, rather, that the docs are not very clear in this situation. Also, I can argue that is a bug almost as well as that is a "by design" behavior. Considering that the code that uses RECNO() and DELETED() in SELECT-SQLs is (IMHO) at least unstable and very easy to be broken by future changes, I prefer to not use them.
As you know, I'm not so unhappy as you with the VFP docs. But in this case I would like some more specs.

In fact, I have some rules of my own on this problem and I have my own explanations for VFP's behavior. But, since I can't base my arguments on docs and I can't prove them by code in 100% cases, I prefer to keep them for my self. Also, I can't asume that the programmer that will change the coed after me has the same experience, has done the same tests, etc. Since it would take me more to explain the assumptions I made about the environment, VFP, etc than it takes me to bypass the problem (and to have solid code in the same time!)...

As you noticed several times here, there are many cases when the fact that we don't know what's inside SELECT-SQL makes its behavior almost non-deterministic for the programmers. This is one of the cases when I agree with you.

The easiest test:

USE ATable
SELECT RECNO() FROM ATable
SELECT RECNO("ATable") FROM ATable

But this is easy to explain.

So, try (also easy to explain):

CLOSE ALL
SELECT RECNO() FROM ATable
SELECT RECNO("ATable") FROM ATable

Try also:

CLOSE ALL
SELECT RECNO("ATable") FROM ATable
SELECT RECNO("ATable") FROM ATable

All these situations can be solved by closing the ATable before SELECTing from it. What happens when you cannot close the table or closing it adds a lot of extra code to bypass the problems done by closing it.

It just doesn't worth it, isn't it? :)

Vlad

>Vlad,
>
>You say there would be trouble EVEN when the alias is specified?
>
>That would imply that SQL chooses, at its whim, to ignore *parts* of specifications.
>Truly, I must doubt that.
>
>Cheers,
>Jim N
>
> >>>>>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