IndexSeek() appears to me to be showing unexpected behaviour when used on tables that are being table buffered.

If I make changes to an indexed field and then use IndexSeek() I can get it to return true for both the old field value and the new field value. I would have expected it to return true for the old value but to return false for the new value which is still sitting in the buffer.

What I'm trying to do here is simply replace the old way we do our form validation when saving. We currently have the table opened twice and use the second alias to do lookups to see if duplicates have been entered. I thought it would be nice to use IndexSeek instead but have found that this function is reliable provided we are using record buffered but as soon as we use table buffered we get anomalous behaviour.

This is easy to reproduce in a browse window with any indexed table. Make sure it is table buffered and then edit the content of an indexed field. You can then see two different behaviours depending on whether or not you step off the record being edited.
Assume you stay on the record you changed all is well, IndexSeek for the original field value returns true, IndexSeek for the newly entered value returns false.
Now step off the edited record to a different one, IndexSeek for the original field value and the newly entered value both now returns true, presumably an index key got created when you moved to a different record even though the original index key still exists as well, I would have expected nothing to have happened to the index until TableUpdate() was issued.

What is even more undesirable is the behaviour that you get if you make the lMovePointer parameter true. IndexSeek for the new value moves you to the edited record in the table but IndexSeek for the old value moves to the next record after the edited record, presumably because it's trying to go to the record with the old value but it isn't there anymore.

David