>>>The following sample shows a situation where tableupdate fails in 8.0, but works fine in 6.0. It will only fail if the table being used has an index on recno().
>
>I see the error, and I think I know what is going on.
>
>When you add records 101 through 110 with buffering on, the added recno() is -1. So we get several negative values in the recno index. When you issue the tableupdate(), I think it is trying to update the recno() index for records other than the record you just added, because their recno() has changed (gone from -1 to the actual recno()), and the error occurs.
>
>If you think I am off base here, try running your code in VFP6, then:
>SET ORDER TO RECNO
>?seek(-1)
>
>The seek() will return .T..
>
>Browse the table, and you will see records 101 through 110 at the top, rather than at the bottom. This is because the negative recno() values are in the index.
>
>I suspect the error occurs in VFP8 because the engine does more to ensure the index is always updated if not current, and we hit a situation where the value for an index expression has changed when the record data itself has not changed, and VFP thinks there is a problem.
>
>Bottom line is the RECNO() index is not reliable if records are added while using buffering. Even if you run in VFP6 or use the workaround, the recno index does not contain the recno() value for the newly added records once the transaction is committed.

Basically, I should remove the index from tables that use buffering, correct?
I never used the index enough in 6.0 to even notice the problem. When 8.0 failed to update though, it got my attention.