>Hi Rosana:
>
>The basic problem is using a transaction date as a primary key. What happens if more than one transaction occurs on the same date?
>
>Any time you attempt to enter the same primary key into a record more than one time, the "uniquenes violation" error occurs -- VFP does not care than one of the records is deleted.
>
>The generally recommended practice is to not use a meaningful field as the primary key -- but to use a code-generated key in a field that the user cannot access. This prevents the user to generating an uniqueness violation.
>
>If you must use the transaction date as the primary key, the code so that the user cannot enter a second trasaction with the same date. If the user has deleted a transaction, code so that the deleted transaction is recalled rather than a new transaction with the same date inserted.
>
>Otherwise, I think the uniqueness violation error is going to be a contiuing headache for you.
>
>regards,

Hi Jim,

Thanks for your prompt reply. I set the date as the primary key cuz this table is a child table, and this table is bound to have one transaction record on the same date only.

Your suggestion of recalling the deleted record rather than adding a new one is good, but the steps of what the user do is, clicking the button, focus to the grid, and then they input the transaction date and other details in grid. So, I think it's quite impossible to recall/add a record before I know what the user is going to input. :-(

Rosanna Man