[AccessD] VBA Unbound data entry / update form

"What I have never done is build a coherent strategy for testing edited
data against the current data in the same record being edited and
handling edit collisions in a responsible manner, without the use of
locks."

JC, I explained this before.  In quite lengthy terms.  Let me try to
summarize.

#1. You should NEVER have two users trying to edit the same field in the
same record at the same time, where BOTH values being entered are
correct.  (ie, there should only be one right 'Last Name' for a person,
yes, it may change, but there is only one correct value for it)

#2. You MAY have two people changing different fields in the same
record.  Not ideal, but granted, some systems may require this ability.

To handle #2 is not very difficult.  Especially if you have a few tools
that help you build your data class/collection class modules.  

Build a Field Class that lets you put a field name, a current value and
a new value.  Then when you build your data class, create a field
collection in it, populated with a FieldClass object for each datafield.
On the Property Let statements, set the Data Class's internal variable's
value, and the NewValue of your FieldClass object (for that field). (Set
a 'ValueHasChanged' property in the FieldClass (returning true if
newvalue isn't blank).  Whalla, when you go to save the data for your
collection class, just loop through your field collection, and if
'ValueHasChanged', THEN update that field, otherwise, leave it alone.

Problem solved.

Drew


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 10, 2008 12:57 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] VBA Unbound data entry / update form

 > Yes, I did, you just ignored it.

Drew, you may believe me that I ignore NOTHING of value.  I didn't get
where I am by turning down free value.

Take whatever it is you are about to "give me".  I can copy fields from
a record to controls and back again.  I can build "transactions".

 >>>>>>>>>>>>>>>>>

What I have never done is build a coherent strategy for testing edited
data against the current data in the same record being edited and
handling edit collisions in a responsible manner, without the use of
locks.

 >>>>>>>>>>>>>>>>>

If your example demonstrates that then I will examine it, else you are
not answering the question I asked (again). 
Since you say right up front that it is a single user system... I have
to assume that you are not answering the question I asked (again!).

I am happy that you are happy with your solution to your problem, but it
is not a solution to my problem.

But I really do appreciate your showing it to us.  I am sure that there
are many people (myself included) that may experience that problem some
day and will be very interested in your solution.

In fact I may very well be building a mini book keeping system very soon
where "transactions" are the answer and edits are not allowed.

There are MANY different reasons for building unbound forms. 
  I have built unbound forms for criteria selection for example.  Not
what you think of as an "unbound form" but in fact it is not bound to
anything so it is technically an unbound form.  Unfortunately that was
not MY question (and this was after all MY thread).  You have
demonstrated ANOTHER use for unbound forms, but again, it does not
address MY question.

John W. Colby
www.ColbyConsulting.com


The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.