>>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