>Hey Ray
>
>Does it really become useless? If you're adding a new record to a buffered table, you could use Indexseek to see if a previous record exists. If not, you do a tableupdate.
>
>Are you saying Indexseek doesn't do this? If you add 2 records in the buffer, do you expect to prevent duplicates within the buffer?
>
I add a new record and don't want to TABLEUPDATE until the user chooses to save or undo (revert). That much is obvious, I think. The situation arose thusly: I have an app where the user can create schedule lines for people in various classes they offer by choosing calendar dates and people to add. When they click my "Apply" button, the records get added, enmasse, to the schedule table. But they can still "undo" those changes so long as the records are uncommitted. Meanwhile I want to generate a new integer PK for each record and check that it's unduplicated with INDEXSEEK. All is well for the first record, because there are no uncommited changes; but for 2nd and subsequent additions, we are FUBAR. I am forced to use SEEK or KEYMATCH, both of which force a record pointer change. I can work around it, but why should I have to?