how to stop controls updating database immediately on lost focus?

[ultra2]

I use VB6 ADO (dataenvironment, commands object)
In my app to maintain data tables I use several control (textbox, datacombo, ect) with set

their datasource and datamember properties properly. On the same datatable maintain form there

are two commandbuttons "post" and "cancel". Id like to update database when the user click on

"post" button, and he could escape from his chages cliclking on "cancel".

My problem is that these controls immediately post its changes when the focus left them. (They

automatically update the phisical database record) so I cant implement my buttons

functionality.

Can anybody help me?

 

[fredericofonseca]

STOP using bound controls and you will avoid that (and others) problem.


If you do everything with plain code you will have FULL control of when and how things get updated onto the database, and you will avoid headaches like this one in the future.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[BobRodes]

I second that. It may sound like a huge task, but it's not really all that difficult, once you get up a routine. The parts are:

1. Have a ScreenUpdate routine, which simply sets all of the controls to the corresponding field value in the underlying recordset ("hand binding"). Call this whenever you move in the recordset, and whenever you post changes to the current record. Most of your fields will be text boxes or combo boxes with the style set to dropdownlist. For comboboxes, you'll need to learn the routine, there are plenty of threads here to tell you how.

2. Have 8 buttons: First, Last Next, Previous (I do |<, >|, >, <), Add, Edit, Save and Cancel. The last two are only visible when the others aren't, and vice versa. I usually have a "FlipButtons" routine. When you're adding or editing, only Save and Cancel should be visible; after you save or cancel, Save and Cancel should't be visible and the others should.

3. I prefer not to update databases through ADO Recordsets. I use SQL Action Queries, and requery my recordsets to reflect the changes. This is conservative, but gives a lot of control. If this is too slow, consider using a keyset recordset to spread the performance hit differently.

Once you have a set of routines that you like, and that you reuse with multiple database apps, consider putting them into a class.

HTH

Bob