Mike,
Of course I agree that "scope", used alone, would make most sense as "the whole table". This is so for virtually every VFP command and function.

The issue at hand is the particular wording used in the Help of SET DELETED, including "...or you include a scope of a single record.. Here it is specific on the "scope" - a single record. "Single" is the keyword here. Just as "NEXT 1" or "RECORD n" limit things to a single record (and it seems clear that these are meant here), there is no doubt that SEEK limits things to a single record.

VFP clearly uses a different definition for "scope" - ALL, NEXT n, RECORD n or REST and these all operate WITH a filter in effect. All commands/functions do too (possibly excepting INDEXSEEK() and RECALL?).

It is this precise confusion (think too of how many ways VFP uses the word "cursor") that leads to problems. The kinds of problems that drive newbies crazy and possibly even away.

cheers

>Hi Jim!
>
>I offer this only to include my perspective on the word "scope".
>
>IMO "scope" refers to the number of records processed by the command, not the number of resulting records. SEEK can be interpreted as look at all records in the index (which may be a filtered index), to find a particular match. Does this mean the scope is one record or all records? The first line of the help says it "Searches a table for the first occurrence of a record whose index key matches a general expression". IMO that means the scope is "the table".
>>
>A filter command can be limited to operate on the next 10 records. That's a scope. It is possible that the next 10 records will only have 5 records matching the filter. The scope is not 5 records. IOW, the scope is not the resulting set of records. Since seek operates on all records in the index, IMO, the index is the scope. Seek results in a single record, but that is not the scope.


>>>>Here's one idea, David:
>>>>
>>>>>Note: SET DELETED is ignored if the default scope for the command is the current record or you include a scope of a single record except in the case of the SEEK command, where SET DELETED is always respected.. INDEX and REINDEX always ignore SET DELETED and index all records in the table.
>>>>
>>>Hi Jim,
>>>
>>>It's incorrect and misleading because implies that SEEK commnad/function has a one record scope when in fact it doesn't. If you believe that such misconception exists, than help topic about SEEK command/function has to be revised. BTW, what do you think about INDEXSEEK() and KEYMATCH() functions.
>>
>>Sergey,
>>
>>Firstly, I *do* believe that SEEK is often/easily considered to have a scope of a single record:
>>1) SEEK has no standard VFP scope clause for good reason - the most you can ever get, and all you can ever get, is one SINGLE record. You can, of course, get none too.
>>2) SEEK will operate differently depending on the setting of DELETED, meaning that you cannot say that its 'scope' is the whole table. It's 'scope' is only the whole table when deleted is set OFF.
>>Mainly, though, the problem is one of interpretation of what is written in the Command reference entry at present. The intention of the documentation *may* have been to refer to VFP commands that HAVE scope clauses. But if this is the case, there is nothing distinguishing this and it is a far more sensible for any reader to infer the common English definition of "scope" than the specially-defined scope meant to limit specific commands' (English) scope.
>>
>>As regards SEEK(), INDEXSEEK() and KEYMATCH(), there appear to be deficiencies in the documentation as relates to them too. I was limiting my comments (erroneously) to commands, excluding functions.
>>I get SEEK() and INDEXSEEK() respecting the setting of (SET) DELETED and I get KEYMATCH() ignoring it, always returning a .T. if a record exists regardless of its 'status' (active or deleted).
>>Consequently, I think that if these are your findings too then you should make a thread under this topic for each of those functions.
>>
>>cheers