I'm venturing back into the unknown for me, I currently use DataCombo's in
my app, but it was suggested that I use regular ComboBox's instead.  Of
course, this means that I will have to write the code to update my db with
the new information.

When I first wrote my app in Access VBA, I remember reading about a "dirty"
property, that if a control was changed/updated that control's dirty
property would be true.  This way if you didn't like the change you could
dump the change and go back.  You could also use the dirty property as part
of a test to see if you changed the value of a control or not.  So my first
question, is there something similar in VB?  I was not able to find a
"dirty" property, but there may be something similar...

Next, my app is all about viewing data in a db, there are approx 40 controls
on my form for displaying the data.  When I'm in the edit mode and hit the
"update" button, would it be better to check and see if any thing has
changed and only update that, or would it be better to just parse through
all the controls and update the underlying db with whatever the current
value is?

I'm still conceptualizing here, and I'm open to any and all suggestions and
advice.

Thanks!

Darhl

That's one reason for a Dirty property, but mostly it's so you know whether
to prompt the user to save data that hasn't been saved yet when they close
the form. To "dump the change and go back" requires that you store the
original value somehow.

No. You have to write it yourself. Not that difficult. Create a Dirty
property for your form. In the Change event of applicable controls, set this
property to True. You may want to get fancy and store each control's
original value (for example, in it's Tag property) and compare to that
before setting the Dirty property to True.  That way, Dirty is only True if
it's actually different from the original (or last saved) value.


Generally, if ONE thing needs updated, you just update everything, even if
the values are the same. It's just easier this way because you've only got
one UPDATE SQL statement. You also only UPDATE one time. IOW, when the user
clicks a Save button or when prompted to save. So, you DON'T update
individual fields after the value changes for each and every control. You
update everything all at once. That way, you're only hitting the database
once to update everything.

or re-query the database

Actually, on an Access form, you can simply undo the control's/form's update
(ControlName.Undo or Form.Undo, IIRC) and it'll revert to the old value(s)
providing it's bound (which is pretty much the norm for Access)...I don't
*think* it works for unbound controls/forms.

This only applies if you're using UPDATE statements.  If you're using a
rs!Field.Value = MyValue, then the one-update thing isn't really an issue,
as DAO or ADO will figure out what's appropriate.  In this case, it would
probably be more desirable to not update if the field hasn't changed.

Two reasons NOT to update everything are 1) if there's some kind of
replication going on (particularly column-level replication) in the
database, in which case updating a field, even if it's to the same value,
may trigger unnecessary replication of the data and potentially cause
conflicts; and 2) if you're using a database that supports triggers,
updating a field unnecessarily may cause the trigger to fire.  This may be
undesirable if, say, you're tracking the time a specific field last changed
and the field hasn't actually changed.



Rob

Show quote Hide quote Lately, I have not only taken to updating only the fields that change, but to
comparing the values first, so that even if they are edited, it doesn't update
them if the new value is the same as the old value.
It means more cursors on the database server end, since there are lots of
different update statements hitting it, instead of the same ones all the time.
But in my case, the server is bored and idle most of the time anyway.
I am now logging every change in every field, so it is worth it to me to avoid
unnecessary updating whenever possible.

It isn't a crime to use a DataCombo, just don't close the list recordset while
it using it. The recommendation is mainly that bound controls can be a pain in
VB, and it often isn't really necessary.

As long as you know the current record in the main recordset, it is pretty easy
to set the ComboBox when the current record changes, and to set the value in the
recordset if the user changes the ComboBox.

VB 10 To Support Native Exe/DLL
Is there anyone uses VS6 on Windows2000 Pro?
Exiting from a Do Loop
Advice on storage and retrieval
Closing recordset
Decimal to Longs
Hyperlink in a CSV
What are &H100&
Real Runtime Control -?-
dhSqlLite.dll question