Cetin,

You are right on all counts. I will use GUIDs from this day on.

Using integer keys works well only on establishing PKs for single table data.

But when it comes to parent-child tables, it really presents problems (for the issues you have already stated). I have been using SYS(2015) for this purpose for quite sometime now. The reason why I posted this thread was to make sure they will be unique always. Thanks for the responses (yours and all the rest) because now, I know better not to use SYS(2015). I guess I am lucky not to encounter duplicates till now!

Thanks!

Dennis


>Dennis,
>Problem#1 is you don't know the key before you actually write (or attempt to write or just explicitly call your function) to backend. Think big from today. That means you need to go and get that value from the server.
>Now think what happens if you need many of those keys say for an import.
>Next think, what happens if you add records to a table which is 'parent' and then to a table that's 'child' of it. Too much dependancy on server. If you have used temporary keys (not the real ones), they would need a 'fixup' for rela values and what if you also need real values back.
>Yet another problem, data updated/added independantly from multiple offices and needs to be merged later.
>
>Dependancy on data server to get the key is generally hidden in many applications. It sounds as if the only problem was a round trip to server. The day you have a need to do something disconnected you feel the pain.
>
>Lots of space with GUIDs is not an issue with today's hardware IMHO. In the past space need was a much more a need and saving just last 2 digits of year caused loss of many $$ in y2k (thanks to fox software, foxpro users even didn't understand what y2k problem was and just walked by fixing the display only:).
>A GUID is 32 or more bytes in human readable form (hex notation + hyphens + braces). It's a 128bits integer which is 16bytes or 4 times of integer otherwise. If you use the worst case form (space wise) of 38 bytes it means 34 bytes more compared to an integer, approximately 1K extra space per 30 records. A trade off I'm volunteered:)
>PS: If you're padding you're already using 10bytes and space impact would be less for you.
>One drawback of GUIDs is that it's hard to read them and that might have an importance during development and debugging. For this I've a small routine that generates then look like as integers and never would be generated with GUID algorithms anyway:
>

>procedure IntGUID(tnInt)
>  return stuff("{00000000-0000-0000-0000-000000000000}",;
>    26,12,padl(m.tnInt,12,'0'))
>endproc
>

>With this routine in test tables I have keys like:
>{00000000-0000-0000-0000-000000000001}
>{00000000-0000-0000-0000-000000000002}
>{00000000-0000-0000-0000-000000000003}
>...
>{00000000-0000-0000-0000-000000000999}
>...
>which are easy to read. And it only requires setting DEVMODE flag to .F. to generate real GUIDs instead (GUID routine calls this one or real one).
>Cetin
>
>>Cetin,
>>
>>What sort of problems/headaches have you encountered with integers? What I really store in my primary key fields are the integers returned by a GetLastNumber() routine then converted to zero padded character strings.
>>
>>Would'nt the use of GUID values as primary key values eat up a lot of disk space? That's already a 36 character field.
>>
>>Thanks!
>>
>>Dennis