[AccessD] VBA Unbound data entry / update form

 This is a mole hill becoming a mountain.

 There are ways to overcome the technical issues.

 What are the political issues ?


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


 >Why would you EVER have two people making changes to the 
same field in the same record at remotely close times?

Two of my applications are call center databases.  In one 
case insurance claimants call in to the call center to talk 
to the adjuster or other call center operators.   There are 
30 such operators.  A person calls in (or the adjuster calls 
out).  A record is created in a "contact" form describing 
the call.  It is just the way that they do business that 
they "group" information in the same record in some cases. 
They might talk to the sister of the claimant.  The time is 
recorded and who talked to them, the conversation etc.

The sister might call back 10 minutes later with more 
information, EXCEPT that the call is taken by some 
completely different operator who pulls up the claim record, 
looks at the "contact" record, and starts editing that same 
exact record, adding more information provided by the sister 
of the claimant.

That is just the way that they do business.  They have 
contacts with a dozen to a hundred DIFFERENT individuals 
concerning details of the claim, everyone from relatives, to 
lawyers to physicians to private investigators, to the 
courts, to the IRS...  Not all claims have contacts with all 
of these kinds of individuals, but any may have contacts 
with any of these contact types or all of these contact 
types.  The company finds it convenient to just keep editing 
one record with conversations with a Private Investigator 
for example.  They MAY create a brand new record for the PI, 
particularly if the date / time is widely separated, or they 
may not.

Many people, potentially editing the exact same record, 
often within minutes of each other.  Edits in the Claim 
records tend to "burst", with bursts of edits in specific 
areas of specific claims within minutes, hours or days, then 
total inactivity for hours, days or weeks.  IOW they "work" 
specific claims to the point where activity dies down, and 
then they might not do anything in that claim until letters 
are received back, phone calls are returned etc. which can 
provoke another "burst" of activity.

Many people, potentially editing the exact same record, 
often within minutes of each other.  You may call it bad 
design if you wish, but that is they way they do it, that is 
the way they have always done it and they are not interested 
in your critique of their methods.  What matters is that it 
works for their purposes.

Now... one person starts an edit and goes to lunch...

John W. Colby
www.ColbyConsulting.com


Drew Wutka wrote:
> LOL.  Well, that is one of the points that we discussed in those
> debates.  It all depends on what kind of systems you build, as to what
> tools are more often used.  Allowing users to modify, or delete data is
> a rarity in most of the systems I build.
> 
> Well, not in the way I think you are referring to. I will have a system
> where I allow a user to change data, but the data change isn't going to
> run into an 'overlap' issue.  For example, the product database behind
> our companies website is maintained by our drafting department.  There
> is not going to be a case where one person would change a product one
> way, and another, another way. Just not how the system is put in place.
> 
> 
> But if you think about it, in many cases, concern about data change
> overlap should really be concern over the design of the database.  Why
> would you EVER have two people making changes to the same field in the
> same record at remotely close times?
> 
> Data in a record represents something real, in a manner of speaking.
> There should only be one right value.  Yes, a value may change, but
> change twice within moments?  I'd say 99% of the time, it's going to be
> bad design that's the real issue.
> 
> Take the helpdesk system I built years ago.  The initial system that was
> in place had a 'comment' field that tracked what the IT personnel did to
> a request.  So you could have multiple techs trying to write to the same
> field.  BAD DESIGN.  The system I built, has interim reports (reports of
> work done in progress) and final reports (reports of completed work).
> These are records put in their own tables.  So you could have a dozen
> techs entering reports on the same ticket, and NO information is
> changed, instead, a record is added for each change made, and thus
> tracking in a much clearer fashion what was done.
> 
> Drew
--