Thanks John,

I thought of that but it isn't really an option unfortunately. I don't understand why the behaviour happens. Perhaps if I did I could work around it. It only seems to be problematic when the parent table is displayed in a grid.

Darren

>Hi Darren ---
>
>Try using a paramterized view for the child grid, i.e.:
>
>CREATE VIEW childview AS ;
>SELECT * from childtable where childtable.parentkey=?parenttable.parentkey
>
>Use this view as the recordsource. In the AfterRowColChange method of the parent grid, do a REQUERY on the child (and in Form Init to get the values aligned).
>
>You can now jump around with wild abandon :-)
>
>
>
>>VFP 5.0a
>>
>>Small problem that is only apparent when using grids. 2 cases both involving a parent grid and a child grid.
>>
>>First case. The parent grid has a calculated field based on a form method. The form method does not change any record pointers in either the parent or child table. In fact it does not change any record pointers in any table in the data environment the grids are tied too. Clicking in the child grid the record pointer always moves to the first record in the child grid. It is impossible to move to any other records in the child grid because the record pointer always jumps straight back to the first record in the child grid. (remove the calculated field and it works fine)
>>
>>Second case. (Different situation) The parent and child grids have no calculated fields. If the record pointer is moved programatically in the child grid then the record pointer will always jump back to the first matching record in the child grid. If the record pointer is moved by keyboard or mouse then all is well. If the parent grid is removed (and text boxes substitued so able to view one record at a time) and the record pointer is moved programtically in the child then all is fine.
>>
>>Anyone got any ideas on these horrid grid things. I'd be very appreciative.