Michel,

How many fields are in this candidate key? Are all of the fields *required* to have something in them once the record finally hits the table? When does this occur in relation to the initial INSERT with blank values..is it a minute or two later?


>Ok, in regards to the candidate key thread created tonight about the ability to assure that no duplicate records would be created, based on the combination of two fields that have to be unique, I would like to add a few feedback.
>
>That approach is much more robust, for avoiding a combination of duplicate fields, than the original approach. However, it's not perfect.
>
>The problem with the candidate key, combined with TRY/CATCH, is that it will assure that no combination of two fields will happen but only when data has been entered. Having said that, I mean that at creation time, when the INSERT INTO is invoked, the record is created but blank values are present. Thus, another user doing the same INSERT INTO will cause a failure of candidate key. Two records got created at the same time with blank values and that means, that from this point, we can no longer add any new record as a uniqueness of candidate key error will be fired by VFP.
>
>So, we need to work on top of this existence approach to see what would be the best way to take care of this last possibility.
>
>One way could be to use the master table which holds all the primary keys of all tables and apply a lock on that record before doing the process. So, while the lock is present, no additional process could be done from the same loop. However, I don't like that. So, any other solution would be welcome.