Hi Jim. Thanks.
>I believe SET DELETED ON is your only viable answer.

I've a vague memory of struggling with something similar in the past, even with set dele on.
I'm sick of getting flak from my supervisor/major user for the system not working 100% (sometimes it's issues like this - sometimes the source data is wrong (to my delight) - GIGO) so I've (with his blessing) put some packs in when opening the tables (just in case set dele on doesn't work)

Terry

>
>
>
>>I've been selecting data into queries and noticed that my results have been going askew. Studying the source table(s) I noticed that there were several recs marked for deletion (i.e. not yet packed) that were getting included in the cursor.
>>
>>So I added ... WHERE not DELETED("SourceTableName")... in the SQL, including the alias so the SQL was in no 2 minds about which of the source tables in the select from list I meant.
>>
>>But made not a blind bit of difference. I was forced to pack the tables to get rid of the spurious results.
>>
>>I must admit to having forgotten to issue "Set DELETED on" in the .Init() of the form but surely the
>>... WHERE not DELETED("SourceTableName")...
>>clause should have taken care of this?
>>
>>UPDATE: I've just found the following info in the Select - SQL Help:
>>
>>Be careful when using, in join conditions, functions such as DELETED( ), EOF( ), FOUND( ), RECCOUNT( ), and RECNO( ), which support an optional alias or work area. Including an alias or work area in these functions might yield unexpected results. SELECT doesn't use your work areas; it performs the equivalent of USE ... AGAIN. Single-table queries that use these functions without an optional alias or work area will return proper results. However, multiple-table queries that use these functions — even without an optional alias or work area — might return unexpected results.
>>
>>So how to get round this?
>>
>>
>>Any advice?
>>
>>'ppreciate it
>>
>>Terry