>>>>>>>>Simple form, one table.
>>>>>>>>
>>>>>>>>Set delete is on in the init of that form.
>>>>>>>>
>>>>>>>>First record of that table is deleted but is shows in the form.
>>>>>>>>
>>>>>>>>When records other than the first one in that table are deleted they don't appear in the form as expected.
>>>>>>>>
>>>>>>>>Anyone can help me with this weird behavior?
>>>>>>>
>>>>>>>What if you GO TOP of the table after the SET DELETED?
>>>>>>
>>>>>>This works... but I don't like it
>>>>>>
>>>>>>I never put a GO TOP before in any form. Why the heck that problem occuring now?
>>>>>
>>>>>Because current record is cached on VFP internal data.
>>>>
>>>>Maybe FLUSH would work ?
>>>
>>>I doubt it, and it would be wrong.
>>>Because the record still exists in the file,
>>>and a developer must go on to RECALL it,
>>>the VFP team can not move the record pointer
>>>without an explicit program command.
>>
>>Flush as I understand it clears any buffers and writes the changes to disk. Doing that should update the caches. Of course the record would exist as a deleted record. Honestly, I haven't tried it, but if flush works as advertised, it should update the cache and resolve the issue if it is in fact a cache problem as you suggested.
>
>The fact is that in this case there is not an simple update data cache,
>but the record should disappear from the cache.
>If that happened, what value would take RECNO ()?

Whatever value it would currently occupy in the table on disk.
What I am trying to say is that FLUSH should update the physical table on disk, and, by extension, update the buffered/cached data.
Perhaps a flush coupled with a grid refresh would do the trick?