No buffering=5.

There can potentially be multiple records and there is a lot of checking that goes on as to the overall state. It will bomb out elsewhere if buffering is not 5. Also, if you look at the view definition "i_key" which is the primary key is being set by default.

Regards
Geoff

>Geoff, I think the problem is that when you insert the record, it has no primary key. SCAN or REPLACE then moves the record counter, causing the new record to be saved if you have buffering=3. I'm assuming there is a primary key in the underlying table. The scan/replace then comes back to the "new" record and tries to change it. But since the data has been saved, you'd need to know the primary key to edit it. As you do not, the record is treated as a new, blank record.
>
>The solution is to use table buffering and do an update at the end. You'll then need to requery the view to get the primary key if you want to change the newly added record again.