>>>>>>>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.
>>>
>>>To make my question clearer, I'm going to talk to myself again. As I understand it, INSERT - SQL is supposed to be better than APPEND BLANK because you can INSERT the key value and make sure it gets in there. However, making keys this way, the key field and value won't be in the INSERT command, so I don't see how it would be better than APPEND BLANK.
>>>
>>>Before, when I generated meaningful keys, I would have the users click an Add button on an edit form and pop up another form with no controlsources, to fill in required fields which would be used to generate the meaningful key. Then I would INSERT these fields and return to the form, where the user, in "Edit mode" could fill in the other values and click Save or Revert, which would do TABLEUPDATE or TABLEREVERT. Having this other form for required fields was cumbersome, and now that I will have a stored procedure making surrogate keys, I want to do away with the other form. Is this all a good reason to use APPEND BLANK instead?
>>
>>Bret, in this case yes APPEND BLANK does look better than INSERT-SQL. In addition to the reasons you've discussed, INSERT locks a record instead of a header, so there's less problems with other users, but that may not be an issue in your program relative to the ID entry.
>>
>>Barbara
>
>Hi Barbara,
>
>Uh . . . doesn't INSERT-SQL lock the header of the table also?
>Bill

Insert-SQL locks header only, and never a record, just imagine what record might be locked here?