>thanks for the response Bill. I will try your solutions. The method for keeping track of the key value was already implemented when I got here. What method do you support for keeping track of primary keys on free standing tables. Maybe I could implement a change without changing a lot of code. Thanks again for your help!

Well, I noted that some kind of "algorithm" was being used to increment the key. Without knowing the reason(s) behind this it's a little hard to say, "Oh, just do it this way..." :-) However, generally the method I use is similar, but basically in simplified form, I just SEEK the appropriate table record in the NextKey table, get a lock on the record, increment the key, store the value to a local var, unlock the record, return the key to the calling program. I have also used a Table Buffering/TABLEUPDATE() scheme on the NextKey table to control the incrementing instead of an explicit record lock, but the principle is the same.

In your case, I would use the Debugger and Watch window to try to get a good understanding of what is happening and why ( that part may not be so easy :-) ), then you should be able to see what changes need to be made to correct any deficiencies you uncover. But, for sure at a minimum, I would store the new key to a local var for return to the calling program before unlocking the record.

When you get the function like you want it, I would create a small PRG with a copy of the function to call and start up more than one instance of VFP to simulate a multi-user environment and exercise the function to see how it will respond when conflicts occur. From there you can figure out a solution that will keep conflicts from hosing your application.