Well, since you using class object, one of there GREAT features is that you
can multiple instances of that object.
So, right after you load the record, cerate another instance of the object,
and have that load up the same values.
then, your update routine can simply check if any of the values loaded have
changed.....
The problem here becomes that each "property" of a class object in ms-access
is not added to some built in collection.
However, What this means is that I would build the class object with a
"field" collection, and not actually write a separate let/get for each new
field (really, if you have to write new code for each control/field you add
to a form, you going backwards to the stone age in terms of productivity,
and wasted developer time). With a medium sized application having a 160
forms, the maintains nightmare here would be incredible.
Further more, you do realize that form is a class object and all of the
controls etc. that you place on a form are already in a object for you!!!
(so, there is only pain, and wasted developer time if you try and code your
own object when ms-access makes one for you!!). do realize that you can have
multiple instances of the same form in memory? (the reason for this is that
each form is a object). And, you do realize that property get/let code can
be placed into a forms code module (and, functions declared PUBLIC in a
forms module become methods of the form - and, inteli-sense will even work
when you do this!!!).
Using a object to just store data from a form makes very little sense when
that same data is in the form......
However, as you said, you doing this much for learning. So, to simply check
for changes in data, simply as mentioned make a copy of your object right
before you allow edit. When the user is done on the form, check each value
for a difference (this actually what ms-access does internally anyway for
you -- it just that you are coding what is built in).
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com 
