Grigore,

GUID is C(38) - I guess you miss the brackets {}. ::).
If you like this, there are compressed forms of GUID, at least without the - signs.

Why we use integers? The trick is to use a surrogate instead of the normal PK what would be normaly a string or an expression that result in a string because it is faster and you do not need that long expression on both sides of an relation. I have tables that have relations to 10 foreign tables. This will result in much bigger table then with integers.

I see the good sides on GUID. I can easier transfer between databases because the record is real unique. But I guess this is not a big problem for the most of us.

Agnes
>Hello, Walter
>
>100% agree. I was more radical than that - I gave up using integers as PK's at all. GUID was my way, generated by the client. It's a CHAR(36). So what? :)
>
>>This is exactly the reason why I won't use the autoincrement feature. Handling new parent records and child records at the same time is virtually impossible in most cases. Therefore it is far better to use the old PK generator again, because you then know at forehand which PK you'd have to use.
>>
>>Walter,