>>
>>I am not 100 sure I understand your question. But here is how I deal with PK. Each table has a PK field (e.g. MyTable_PK I). And the PK is an identity column. So, when a user adds a record to a table, the BIZ object gets the Identity Number set by the SQL Server and stores it into the field. Therefore, the Cursor Adapter can use this PK to edit a record or do whatever it is necessary.
>>I am wondering, why do you use a compound PK? Could you give an example? Again, in my case, each table has a PK which is an identity column.
>
>Well, referring to a compound PK. I have a table of services:
>
>

>INTER - INTERNATIONAL
>IMPOR - IMPORTS
>EXPOR - EXPORTS
>LOCAL - LOCALS
>

>
>And for each service a have several rates:
>
>

>INTER - INTERNATIONAL
>     CO - CORPORATE RATES
>     PR - PREMIUM RATES
>IMPOR - IMPORTS
>     IS - STANDARD IMPORT
>LOCAL - LOCALS
>     LS - LOCAL STANDARD RATES
>     LP - LOCAL PREMIUM RATES
>

>
>And the rates changes almost every month according to our suppliers. I use codes instead of identity columns so that the user can recognize them. Is that bad? Identity columns can improve that?
>
>I hope you could understand it.

IMHO, I would not use Identity Column for something that user will see and account for. I would have a PK - Identity Column - in every table as a way to have the view or a Cursor Adapter cursor to update the table.
Then create a field for the code to indicate whatever it must indicate (e.g. the rage). That is, the user then will not see the PK but rather a business field value. What I am trying to say is that PK field/Identity should be a separate field from the business field you use for your suppliers.
Hopefully it makes sense.