>>>>My abbreviated 'vcr' buttons class has but 2 buttons: 'Add' and 'Edit'. Upon clicking one of them, their captions change to 'Save' and 'Undo'. The basic functionality is as follows: Add--> append blank, refresh, controls readonly = .F.. Edit--> Controls readonly = .F. Save--> if any fields have been updated send changes to audit trail and tableupdate. Undo-->tablerevert.
>>>>My question arises with the last little bit of functionality. If a user clicks 'Add' and then begins to add a new record, then changes her mind and clicks Undo, I would like for the newly appended record to be deleted. Seems simple enough; just check if the form is in add_mode or delete_mode, as set by the add or edit buttons, and then delete or tablerevert() accordingly. But the delete doesn't seem to be working. It gives me unique key violation errors (I don't assign a unique key until the user clicks save) first, and then asks if I want to revert. All's well in the end, but the road is pretty ugly. All of the minor difficulties involved has made me wonder if I am doing things the hard way. Is there something wrong with the way I am trying to do this? How do you handle similar situations? Do I need some basic restructuring? Does anyone have a graceful class that handles this that they are willing to donate? Any suggestions or related expertise is greatly appreciated.
>>>>
>>>>Erik Moore
>>>
>>>It looks that you hit common problem with APPEND BLANK. When you add a record (even blank) you already filled primary key for this record (supposedly blank too). Deleting the record doesn't affect indexes which include all records (both deleted and non-deleted). Therefore, when add one more blank record (next APPEND BLANK) you violate primary key (one more blank key).
>>>Basically, the good design uses INSERT-SQL at the end of 'add' process instead of APPEND BLANK at the beginning.
>>
>>Mr. Edward, Sorry to trouble u once again, But if we will use, Insert Sql at the end of add process, then how will we input the values from user.
>>
>>Pls Advs.
>
>if the designer doesn't want to use memory vars to hold the values to wait for the insert into..., he can add a stored procedure that fills the primary key field when append blank is issued.

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.