>My suggestions of using a temp file or updatable view as the grid's data source are simply an attempt to remove the index from the editing scenario, then post edits to the indexed base table.
>
>It seems that your idea of saving the current key and using it to reset the record pointer should work and would require less coding that my suggestions.
>
>I use grids occasionally (with combo boxes and row highlighting) for simple data entry, although none of these contained combo box values that fueled the base table's index as your's does. Generally I use grids as 'pick lists' to launch a maintenance form.
>
>Im sure I will be running into this problem in my own project and will let you know if I find anything interesting.
>
>Best Regards,
>
>Todd

Thanks, Todd. In addition to this idea I was also thinking about saving the whole current record content in a form property (e.g. scatter name thisform.oCurRec) and then in Next/Prev buttons compare this with current record values and perform seek only if they are different. I should also set near off (then restore) and I have a slight risk to skip records by this approach :( Another more complicated idea would be to save NextRec and PrevRec on each record movement and use those properties in Next/Prev buttons instead of its logic. I'm still thinking, which one of these ideas to implement. The second idea seems to be more accurate. Besides, since it's a general problem for our framework, I asked this question all my colleagues, but didn't get any replies.