>>>Looks pretty good, Bret. I would store a numeric value, even if I were using a character value in my tables (in VFP3 I use a character field with the numeric value padded with 0's)
>>>
>>>You might consider adding a 'pause' in the reprocess loop. Networks can actually slow down when several people send multiple lock requests close together. Maybe add an inkey(.1) or inkey(.05) to the loop.
>>>
>>>Barbara
>>
>>I use vfp3. Why do you use a character key field in version 3, but not version 5?
>
>Bret, VFP3 has problems handling numeric fields in Combo boxes. You may be using your IDs as the bound field in combos, particularly for lookup tables. Using Character fields avoids the problem, and it's easy to use a PadL() function to stuff leading zeroes into the character field.
>
>In VFP5, the combo problem was fixed.
>
>HTH
>Barbara

Here's another thing. Now that I'm using this stored procedure, tastrade-style, to make the keys, it seems like APPEND BLANK will work better than INSERT - SQL. That is the opposite of what I've always heard. But I don't see how, with this system, I can even use INSERT - SQL if I don't have another required field. Shall I just go ahead and APPEND BLANK?

For the benefit of people who didn't see the snipped part of this thread, I'm using the tastrade technique of making surrogate keys. The key fields have a default value which is a function in Stored Procedures called newid(). This function gets the next available key from the appropriate field of a keys table which is then incremented.