Isn't SCAN enough to ensure an update of the pointer in the related table?! This example does not prove that SKIP 0 also updates that pointer. Also, the LOCATE command is nonsense here, or isn't it?

>SKIP 0 && This is zero?
>

>SELECT MYParentTable
>SET RELATION TO Key INTO ChildTable
>LOCATE
>SCAN
>   SKIP 0
>   ? ChildTable.Key, EOF("ChildTable"), BOF("ChildTable")
>ENDIF
>

>not tested because I never used this, since I use VFP. This are my memories from CLIPPER days :o)))
>
>
>
>>In many of our forms we have a SET RELATION from the parent to the child table. After the parent moves to a new record the code does a SKIP, SKIP-1. It seems like this is to jolt the child record pointer into moving.
>>
>>Anyway, the SKIP, SKIP-1 is causing me fits because we have changed the cursors to have smaller subsets of records and in some cases no records. Just looking for a nice small bit of code to replace the following two examples of code which do not work ...
>>
>>** example 1 - empty cursors still have a recno() = 1
>>SELECT obligat
>>IF RECNO() > 0
>> GO RECNO()
>>endif
>>
>>** example 2 - not work for empty cursor. empty cursor can be eof() and !bof()
>>DO CASE
>>CASE EOF() AND BOF()
>> RETURN
>>CASE EOF()
>> SKIP -1
>> SKIP
>>OTHERWISE
>> SKIP
>> SKIP -1
>>ENDCASE