I agree 100% Ken.

I've also often wondered what a newbie must think when they read "... scopes to the current datasession.". How a newbie would 'get' that is beyond me.

cheers

>Thanks, Jim.
>
>Hmm....
>
>Well, I might eventually realize, as I read that, that GOTO [some record] would be a command with "a scope of a single record". But I already knew that a bunch of commands don't respect SET DELETED. My problem is that I didn't know that GOTO doesn't respect SET FILTER--and there's nothing in the Help for SET DELETED or for GOTO that would tell me that.
>
>Furthermore, the Help for SET FILTER says:
>
>"All commands that access the table respect the SET FILTER condition."
>
>I would consider GOTO to be a command that accesses the table.
>
>So I see one DOC bug here, and one fairly important DOC ER.
>
>Ken
>
>>Hi Ken,
>>
>>It's partially documented... but as is often the case, not where one might be looking.
>>
>>The following is from Help for "SET DELETED command":
>>SET DELETED is ignored if the default scope for the command is the current record or if you include a scope of a single record. The exception exists with the SEEK command, in which case, SET DELETED is always respected. INDEX and REINDEX always ignore SET DELETED and index all records in the table.
>>
>>
>>cheers
>>PS It was good to see that they now mention the exception of SEEK.
>>
>>
>>
>>>Thanks Sergey,
>>>
>>>>The GOTO < Record # > command pays no attention to SET FILETER or SET DELETE ON.
>>>
>>>That's not documented in the Help for the GOTO topic, BTW.
>>>
>>>>When BROWSE command runs, it issues implicit LOCATE if current record doesn't satisfy filter conditions.
>>>
>>>And I'm still confused. It's a good thing I'm not afraid of appearing ignorant online. <g>
>>>
>>>It seems to me that in my code, if the BROWSE issued LOCATE, then the second BROWSE would show the pointer on the first record, not the second.
>>>
>>>If I do this with the same cursor:
>>>
>>>

>>>GO 10
>>>
>>>nRec = RECNO()
>>>
>>>SET FILTER TO IntField <> 10
>>>
>>>LOCATE
>>>
>>>? RECNO()  && 1
>>>
>>>GO nRec
>>>
>>>BROWSE  && Record 10 is not visible. The pointer is on Record 9.
>>>

>>>
>>>The Help for LOCATE says:
>>>
>>>"If you use the LOCATE command without the FOR expression, Visual FoxPro positions the record pointer at the first logical record. This is faster than using GO TOP when a filter is in use or when DELETED is ON."
>>>
>>>From this I conclude that a bare LOCATE should always put the pointer on the first record in the table. Granted that "logical" record isn't the same as "physical" record, but "first" means "first", right? It doesn't mean "the first record that the filter will let us show in a BROWSE window after the record we went to that can't be shown", right? Or, in the case of the above code, "the nearest record that satisfies the filter"? With no index on the cursor, it doesn't matter what nRec was; the first record is the record whose fields contain 1 and "1". It looks to me like the BROWSE isn't just issuing an implicit LOCATE. It's a lot more complicated than that. It's more like:
>>>
>>>

>>>IF NOT EOF()
>>>     LOCATE REST FOR [filter condition]
>>>ENDIF
>>>
>>>IF EOF()
>>>     SKIP -1
>>>
>>>     DO WHILE NOT [filter condition] AND NOT BOF()
>>>          SKIP -1
>>>     ENDDO
>>>ENDIF
>>>

>>>
>>>Have I got this right?
>>>
>>>>>I was going to suggest that you *can't* get back to that record because under your filter, it's no longer visible. It doesn't exist in this view of the table; that's why it's "out of range". So I started messing around with some simple demo code, and I discovered this:
>>>>>
>>>>>

>>>>>RELEASE ALL
>>>>>CLEAR ALL
>>>>>CLEAR
>>>>>
>>>>>LOCAL x, nRec
>>>>>
>>>>>CREATE CURSOR foo ( ;
>>>>>     IntField I, ;
>>>>>     CharField C(10) )
>>>>>
>>>>>FOR x = 1 TO 10
>>>>>     INSERT INTO foo (IntField, CharField) ;
>>>>>     VALUES (x,TRANSFORM(x))
>>>>>ENDFOR
>>>>>
>>>>>GO 2
>>>>>
>>>>>nRec = RECNO()
>>>>>
>>>>>? nRec  && 2
>>>>>
>>>>>? CharField  && "2"
>>>>>
>>>>>SET FILTER TO NOT ALLTRIM(CharField) == "2"
>>>>>
>>>>>LOCATE
>>>>>
>>>>>BROWSE  && The record that contains "2" isn't visible, pointer is on record 1
>>>>>
>>>>>? CharField  && "1"
>>>>>
>>>>>GO nRec
>>>>>
>>>>>* With this commented out, the next line returns "2", which should be
>>>>>* impossible, because that record isn't visible; it's excluded by the filter.
>>>>>* If this line runs, the browse window shows the record pointer on the second
>>>>>* record, where CharField = "3", and the next line returns "3", which is what
>>>>>* should happen with or without the BROWSE.
>>>>>*BROWSE
>>>>>
>>>>>? CharField
>>>>>

>>>>>