>It seems a little pointless to generate the PK outside of the database when the only way to guarantee that it is unique is to let the database generate it.
>
>The method that I use is to call a SP that inserts the row, stores the value of SCOPE_IDENTITY() - or @@IDENTITY if that is what you prefer, then performs a SELECT ... WHERE PK = @MyID to return the newly inserted row back to the application. This means that the application will pick up the results of any defaults, computed columns, or triggers that affect the data.
>
>As far as I can tell, this is the only method to insure that your dataset is not out of date with the database.

I see your point, but I use a guid (uniqueidentifier) for my PK for most of my new tables. A guid is (in theory) unique so it doesn't matter who generates it.

In my current project I have one table (well maybe two tables) where I don't use a guid, in this case the PK is a bigint that is given to me in the form of a serial number from a device manufacturer (they promised me that they can't duplicate the S/N {yeah yeah we have all heard that one before})

Any general thoughts about using a guid as a PK (other than the fact that it it uses a lot of disk)?

Einar