>>In the January 1998 issue of FoxPro Advisor, on page 74, is a tip of the
>>month which warns about undocumented movement of the record pointer. It
>>seems that if a cursor is row-buffered, moving the record pointer commists
>>changes just as if TableUpdate() had been issued, but WITHOUT the benefit
>>of the code that may have been written to handle a failed TableUpdate().
>
>I may be misunderstanding your intent, but this is not undocumented
>behavior. RowBuffering has always been documented to commit changes on a move
>of the record pointer.

Specifically,
1. Changing the Order property of a Cursor object automatically moves the record pointer to the first record in the table. If's as if GO TOP or LOCATE were issued.

2. GetNextModified() triggers Field and Record level validation rules as if an attempt was made to move the record pointer. This record pointer movement happens behind the scenes - a break point on RECNO() doesn't fire.

3. Changing the index tag of a grid's RecordSource when the grid, or one of its members has focus, moves the record pointer. The only circumstance Steve P. Dingle (the one who submitted the tip) found were the record pointer is not moved is when the currently selected row is the first visible row in the grid.