Hi Agnes,

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

You are definitely right about integers being faster than character data for comparisons. But there are relatively few situations where the difference would be noticed by a user. And there are some significant advantages to using GUIDs. From "Creating Visual FoxPro Applications with Visual FoxExpress" by Bob Archer and Dan Jurden,

"The GUID can be generated at the client and the server. There is no need to communicate with another machine to generate a GUID value, which increases performance, especially in bulk data processing situations.

No support file (AppIDs) is needed to maintain the last value used. In addition, because there is no support file to query, there are no multi-user performance or conflict issues.

If you're dealing with a situation where data entry will take place offline, or if data from disconnected users will ultimately be combined, GUIDs will maintain their uniqueness.

In a remote or distributed deployment, there is no network traffic generated, nor is there a back-end hit needed to create a GUID value."

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

All the more reason to consider GUIDs. Of course, if you ever actually browse your tables, make them the last fields of the table, because they sure are ugly to look at.

Regards,

Jim