Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Adding records... or not.
Message
 
À
03/06/1997 10:51:24
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00034710
Message ID:
00034737
Vues:
42
>>>>>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.
>
>For me it's enough to use Value properties (for most cases) when time is ready for Insert-SQL.

control.value will work -- i prefer the stored procedure method...
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform