Hi Jim,

yes this is a possibility. But I have decided to not use this approach for myself.
I have the feeling that it will wast to much space and time. The pk itself grows from 4 up to 38 bytes. The index file will grow as well. Any table that point to such a PK will grow the same way. (And some strange tables here have now more then 6 relations wich are indexed as well). And to may knowlege comparing an integer is always faster then comparing such a large string.

I feel not happy with the creating on table. because it adds a lot of stupid code.
In the end it means:
-create a record on the table
-get the new pk
-requery the view so that it catches the new record
-place the record pointer to the "new" record.

-No easy undo

And, yess to have the pk for foreign keys in other tables is the main reason to first create the pk.
The other one is, that you may CREATE a new record that way. But if you, once created, try to alter without previous REQUERY(), you will fail because the keys will not match. And if you REQUERY() you need to find the last record (or you will end up on top of the view) and normaly it's identified by the pk best ...

So to me inserting a view into a table without prior knowlegde of the PK is nonsense.
And since a APPEND BLANK to the table create a new record with a easy to catch pk (and it's the bussiness of the table to "know" about the next pk) I prefer it this way.

Agnes

>>I may add to Hilmars that if you add the pk to the view, a concurent view somewhere else will not know about the new pk and may use it also. You will not know when a new view - record is written to its table. Then you will have two new records (in view) with the same pk.
>
>You can overcome this problem by using GUIDs for your primary keys. And there are some instances where you may need the primary key before you save the view to it's table. For example, if you add a child record in a child view, you will want to populate it's foreign key with the parent's primary key.
>
>Regards,
>
>Jim