>You mean the PK of the parent of it, for the relation ? If so, I'm not assigning it. As in its parent, which is a child of the main one, and its working fine there.

So, from what you are saying, the PKs are being auto-assigned by Codemine right?

>Even if I edit the contents of the bottom line of the grandchild, and them click the save button in the main toolbar, the record point jumps to the firs occurence of the grandchild grid.

OK. So you are saying that even if you don't add a new record, if you edit the last row in the grid and then click Save, the record pointer jumps to the first position/row in the grid? If so, let's forget the New record for the time being and see what is actually happening in the grid.

If you click into the last row in the grid, everything is OK until you click Save after editing the data in the grid. Am I assuming correctly here? If so, go into the CDE and in your rule object, in the BeforeNav hook, do as follows :-

IF m.cWorkarArea == 'Grandchildtablename'
   SET STEP ON
ENDIF

Obviously, when you load the form, this will probably fire a few times - just RESUME or type Ctrl+M to carry on. Then, go to the grid in question, edit the record and then Save it. See if you hit the STEP assignment in the BeforeNav hook. What we are trying to do here is see whether Codemine is moving the record pointer in the grandchild table as a result of calling the Save method of the form. If after pressing Save you do hit the SET STEP ON, then you need to look through the callstack and see what is moving the pointer. If the grid jumps to the first record and the BeforeNav hook isn't called, then something else, other than Codemine is moving the record pointer. If this is the case, then what you could do is set a watch in the watch window based on RECNO('Grandchildtablename'). Just before you Edit/Save the last row in the grid, set a breakpoint on this expression. When the RECNO('Grandchildtablename') value changes, the program will stop. Again, in the callstack or the trace window, you should be able to see what is happening that is moving the record pointer.

This may be a bit of a "red herring" in that it may appear that the pointer in the Grandchild table is moving. However, it might be that something in the Save is actually forcing a requery or pointer movement in the child (parent) cursor which is in turn re-selecting the grandchild recordset (because they are related) which will subsequently put the pointer in the grandchild table in the first position.

The problem with the VFP grid is that it has a number of quirky behaviours. For example, sometimes, if a form contaning a grid or the grid itself is refreshed, the grid can temporarily move the record pointer and then move it back to where it should be. When you have related data that is restricted by either a SET RELATION TO or SET KEY command(s), the related data in the immediate child dataset(s) can end up getting requeried because of movement in a grid containing parent data. It used to happen to me from time to time when I was using Fox data.

Try some of these suggestions and let me know how you get along.

Best,