>
>Dave's suggestion would seem to work for me except for a couple of issues; 1. Adding the unique key before the tableupdate() affects the getfieldstate command that tells me if the record has even been touched. "2" $ (getfldstate(-1)) returns .T. if the unique value has already been assigned. 2. (minor) if the user changes her mind as whether to add the record, the next unique value from the idnums table has already been used (wasted).
>
>Edward- INSERT SQL would seem to work... but then I would really need a separate entry form without databound controls (or temporarily unbind the controls on the form; cumbersome) would I not? A little late in the development effort for that it seems. Is this how you do it? Anybody else with insight? This has to be a prettyy common dilemma. Thanks for your help.

1. If the user doesn't assign the unique key, then don't bother to check the key field for changes.
2. I've heard this argument a lot, but 'wasted' keys are a great barometer of how the app is being used. The fewer the better. If there are a lot of 'wasted' keys that means either the app is difficult to use or the users are wasting a lot of time entering things before they are ready. In either case, it's time for a rewrite or training.

I'm with Dave on this one, use a stored procedure for appending records.

And no, IMHO, you wouldn't use a seperate form for INSERT-SQL, you'd remove your controlsource references and put code in your refresh to manually stuff values into the proper controls, or you could use memory variables and a scatter in the refresh (less coding, but I've grown to hate memory variables). You'd also need to add similar code to your save function.

HTH