>>The EXIST key word is like a NOT EMPTY (or testing _TALLY, but you can't do that in a SELECT-SQL). Ie: if the inner query is not empty, the record is included in the main query result. If the inner query is empty, the record is not included in the main query result (obvious, isn't it?:)).
>>
>>In your case, the inner query doesn't depend on the main one, so, the result is the same for all records in the source table. Since this result of the inner query is not empty and you test with !EXIST, the condition is false for all records, so the main result is empty.
>>
>>This also explains the other sample you gave in this thread.
>>
>>Vlad
>
>Vlad,
>Sorry to say this but you lost me with this explanation. I think its just because I'm trying to use NOT EXISTS instead of a straight WHERE EXISTS. Plus too, my inner query isnt empty. Regardless, I did figure out my problem here, see my response on this thread to Jim Nelson. Thanks anyway! :D)

This is from the Help file:

"When the filter condition includes EXISTS, the filter condition evaluates to true (.T.) unless the subquery evaluates to the empty set."

So, the query is something like:

SELECT ... WHERE EXISTS (SELECT subquery...)

If the subquery evaluates to a non empty result, the condition is true. If the result is empty, the condition is false.

In your case:

SELECT * FROM ALPHA_X WHERE NOT EXISTS( ;
SELECT * FROM ALPHA_X WHERE stype="WL " AND progtype="NP") ;
INTO CURSOR ALPHATMP

The subquery:

SELECT * FROM ALPHA_X WHERE stype="WL " AND progtype="NP"

returned more than 5000 records, so it was not empty. Also, the subquery didn't depend on the main query, so, you had the same subquery result for each record in alpha_x. So, the EXISTS evaluated to true for all records in your table. But you used NOT EXISTS, so, the condition evaluated to false for all records in the table.

That was like:

SELECT * FROM ALPHA_X WHERE .F.

This is why you had the empty result.

So, the problem is not with adding table aliases, but with the logic of the composed SELECT.

I wanted to clarify this problem, because, after this thread, the conclusion could be that VFP has problems when using the same table in the main and in the subquery, or with aliases. I already heard about this type of problems from many FoxPro programmers, but I couldn't find a single case to prove it. Although, the SELECT problems (most of them unreal) are used a lot as a "valid" reason to not use VFP. And I am a little tired to hear again about cases like that. :(

You know, tomorrow maybe you'll hear a FoxPro "programmer" saying: "I just read a thread on UT proving that the EXISTS doesn't work properly in VFP's SELECT."...

Vlad