We use bigints for our PKs. I'm not against using GUIDs for storage reasons ... we have a GUID in every table but we don't use them as PKs (they are in there for future use, in case we need some unique identifier for merge/replication or something). However, the main problem, IMHO, with GUIDs is NOT the excess disk space they take up (with the price of hard drives nowadays, that's not an issue at all), but the bandwidth they take up coming down the wire. For that reason, we NEVER retrieve the GUIDs into our DataSets.

~~Bonnie


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