>>>
>>>The problem with GUID (I think in my case) is I want the identity in this particular table to be in sequential order and no numbers missing. And with GUID, as I understand, another "procedure" or "process" can grab the number.
>>
>>Extremely, extremely unlikely!
>>
>>Identity columns are not necessarily PKs. An Invoice # could be the invoice ID and should have no gaps. The PK should be different and used just for table joins.
>>
>
>In my case the PK number is actually order number. Order number should be viewed by the user and used for locating orders. And this order number/PK will be used for table joins too. I see no reason to have a separate PK and separate order number as they could serve (and have been working in VFP app) as one and the same. As far as GUID, I will have to learn more about it. But so far I want to try implement the approach of a table storing the PK numbers (order number or whatever).

The PK is not supposed to be visible or meaningful to the user. Not only that, but if you use order# + line # as the primary key in the line items table, you will have to do substring manipulations and/or cascade updates when the user changes the order #. This is even worse with a grand-child table. With a meaningless PK, there will be no need for such cascade updates.


>
>Thank you for your input.