>Hi Cetin,
>
>>Why are you inventing newid when SQL server has one NewID() or IDENTITY or Timestamp.
>
>You raise a good point. A VFP/SQL application I took-over about 3 years ago has all its tables with integer pk fields, but the pk values are allocated via. a single 'control' table (called UniqueID), with one record for each table. Unfortunately none of the PK fields are auto-incremented identity fields.
>
>I have only just discovered that SQL also has a NewId function (otherwise I might have called my VFP function something else!), but this produces a very complicated unique-identifer - my application only requires integer values.
>
>Regards,
>Alan

Alan,
Yes SQL NewID() returns an 128 bits integer (a GUID) and it is the ultimate uniqueid (actually even datatype is called uniqueidentifier).
It doesn't matter they are not identity fields. You can define them as identity fields now (I prefer GUIDs). What you do is already stored in a similar way in system tables and no need to invent another uniqueid table IMHO. That newID() style is for VFP (and I find them to be better than VFP autoinc fields personally). With integers it doesn't matter if an id is 1 or 12345 as long as it's unique, right? Then there is timestamp value if you desperately need a unique numeric value (it's 8 bytes - 64 bits integer). Timestamps are guaranteed to be unique within database where GUIDs are guaranteed to be unique worldwide.
PS: In SQL2005 also there is a new one called NewSequentialId() that still returns a GUID sequentially. Not guaranteed to be unique worldwide but within a server.
Cetin