>It is not the job of the view to assign a PK...that's the job of the database.

I tend to agree. I see practical problems with assigning the PK in the view; for instance, I might open the table directly at times. I might also assign the PK in the forms, but in principle, I agree that "that's the job of the database".

> Requery using the PK to get the record back.

How? In the view, the PK has the value zero, so it is tricky to search for the record. Or do you mean, with requery()?

>Another option is to make the PK updatable and just change it in the view after it's been assigned by the database.

Here, too, the question arises how to obtain the recently assigned value.

My function SerialNumber() gets the number from a table, and updates it. If I query this table, I am afraid another user might increment it in the meantime.

Come to think of it, I might embed the record saving in a transaction - that would avoid the above situation.

The view PK need not be updatable (I think): the data is already in the table, and there is no need to change it. I only need to get it back to the view.

BTW, assuming we are willing to upgrade to a later version, do you know how all this would work in a later version, with autoincremental fields? I suspect the value would not be read back to the view, either.

>>How should the following situation be handled?
>>
>>The primary key in a table is assigned through a function, through its default value.
>>
>>In a parameterized view (local view), the primary key field is marked as a primary field, and is not updatable. All other fields are updatable.
>>
>>When the user creates a new record (the datasource is the local view), and saves it, the table receives its PK correctly (through the default value), and all other fields get updated correctly. However, the PK in the view still has the value zero, since no data is returned from the view to the table. Therefore, if the user does changes to the newly created record, these changes can't be saved, since the PK is invalid. There are also a few other problems, related to the missing PK in the view.
>>
>>If, on the other hand, the user closes the form (the one that uses the p-view) and opens it again, the data is read correctly, and the record can be saved. Also, I might do a requery(); but it seems inefficient to requery() the entire set of data every time a single record is saved (only for new records). I thought there must be another way.
>>
>>I think there might be some bad design in the structure explained above, but I can't spot it.
>>
>>TIA,
>>
>>Hilmar.