>Can you establish a primary key for the table and trap the error in the case that a second person/process attempts to create a duplicate key?

The problem is not to trap is someone is creating a duplicate key. The problem is that many times a day, I'd have two users doing the same transaction at the same time. At the time they do it, they are both ok with the validation. So, they get inside the condition and proceed with the INSERT INTO command. I was thinking of using an alternate table to keep my lock in there on a specific record that would be related to the main table I have to insert into. So, I would lock a record in that alternate table based on a member ID. I mention member ID here as the situation occurs when a member is firing two clicks from the browser at the same time. As multiple WWC VFP applications can take over the request, they can all process the same kind of hit from the same user at the same time. I say same time but in reality it's that one WWC VFP process is not terminated when the other one kicks in. So, the first click of the user bypasses the validation and proceeds with the INSERT INTO. Which is ok in this case as no record for that particular user has been created so far. Then, the other click also bypasses the validation as the first click process is not completed yet. So, we end up with a duplicate record. Using an alternate table, I could issue a lock on a record over there just before doing the validation. Then, as long as the initial process is not completed, the validation won't proceed on any other process.

So, basically, the need here is to lock something somewhere in order to allow a process to execute a series of command before another process go into that same loop of commands. By doing that, it will assure that once the initial process is done, a record has been created and the second process won't be able to create the same record as it won't be able to get into the required code as long as the initial process is not completed.