[AccessD] Double Data Entry Requirement

On 20 Apr 2005 at 11:07, Charlotte Foust wrote:

> I've seen this kind of requirement before.  It's a holdover from the
> green screen days when operators did heads down data entry all day and
> there was little or no validation at data entry and the terminal
> keyboard was limited.  QA relied on data being entered twice to make
> sure it matched and then handling exceptions.  It doesn't make a lot of
> sense in the newer languages, and I have dealt with it in the past by
> suggesting that if the business rules were clearly defined, the data
> could be verified in code either before or after being committed.  A
> couple of problems with double entry verification are that the second
> time could be incorrect or both could be incorrect but might match.  At
> that point you have validated garbage.  This criteria is often suggested
> by people who have no clue as to how validation can be done in code or
> by the input form itself.
> 

There are  many cases where no validation can be done in code, A prime 
example being the PNG Electoral Roll where we had up to 50 operators keying 
in data from enrolment forms for months. There is no way to validate DOB, 
name etc entries other than eyeballing printouts or double entry.   

We also used double entry when recording progressive results of elections 
for updating the results website.  Those again couldn't be validated in 
code and had to be accurate when posted.

> I am working on a proposal and one criteria is to "provide for the entry
> of... data twice to ensure accuracy." I thought of three methods of doing
> this. 1. Create a table for the second data entry and then compare the
> record with the first table.  Delete the record(s) of the second table when
> they match. 2.  Use an unbound form for the second data entry and compare
> the results with the table to ensure they match then delete the data. 3. 
> Recommend the second person print the record and compare the documents
> without doing a double data entry.  Suggesting it would take less time and
> therefore save money.  There is the issue of paper, printing, etc.....

Option 3 is the least accurate for a number of reasons. I'd avoid it if 
they are prepared to accept the costs of double entry.

The preferred double entry methods depends on on the situation.  

Can you have unvalidated data in your records? If so, put a flag field in 
the record and use your Option2.  Do a comparison of the results and then 
update the flag - you need to allow for modifying the record if the 
original entry is the incorrect one.

If you can't have unvalidated data, you need to store the first entry in a 
temp table until it is validated. Again, you can use an unbound form for 
the second entry, but this time instead of setting the flag, you move the 
correct(ed) data to the main table.




-- 
Stuart