>>>If you are using the view, the view "sees" the new record first, then it sends the update to the table when you do tableupdate or move record pointer or whatever...
>>>
>>>No conflict, "Default Value" property of table or view field is just that, a default value in case the field is empty at the time it is inserted in the view/table.
>>>
>>>If you do APPEND BLANK using the table, the UDF call of the table triggers
>>>
>>>If you do APPEND BLANK using the View, the UDF call of the view triggers, by the time the record "arrives" to the table, the PK field already has a value, its not blank, so the UDF call of the table does not trigger.
>>>
>>>Remember, "Default Value" triggers when the field is empty, so we dont get an empty field. Sometimes we forget the obvious...
>>>
>>>Carlos
>>
>>I tried this (putting my function SerialNumber() both in the table and in the view), and it turns out that both the view and the table fetch the primary key default value. Worse yet, the view gets the primary key value first, then the table overwrites that with a new value. Skipping values would not be a problem (the user doesn't see the primary key), but the view has the wrong value (not the same as the table), therefore, I still get the update conflict when I save a new record, make changes, and then save it again.
>
>Did you check the field as updatable in the view? If you dont, what you describe will happen.
>
>Carlos

Great! Yes, that was the problem - I had forgotten to mark the primary key as updatable.

Your solution worked perfectly; it is both easy and effective. I can now open either the view or the table, and doing the suggested changes to the view is quite simple.