Duplicate Data Entry for Access

<< Click to Display Table of Contents >>

Navigation:  Other Topics > Smart Access 1996-2006 > Jan-2002 >

Duplicate Data Entry for Access


Garry Robinson and Taha Kass-Hout


Redundant data is bad, but double data entry can be good.

Garry Robinson shows you how and why.


ABOUT 12 years ago, when the mining company

that I worked for ran all of its word processing on

a Digital Vax mini-computer, there was a legal

secretary who lost a 50-page legal document. After 15

minutes of looking, the system administrator had to

explain to her that retrieval of the document was going to

be difficult and wouldn’t retrieve all of the work that

she’d done that day. Funnily enough, she said this was

okay and that she loved “a good type.” She went back

down the corridor and hammered out all 50 pages again

in a few hours. Unlike programmers, there are many data

entry and computer-trained people who enjoy using a

keyboard. Likewise, you’ll find that a large number of

these people also wouldn’t do a really good job of

checking data entry against written reports. Yet there are

many applications where it’s absolutely critical that the

data entered be verified.


This brings me to a challenge that co-author Taha

Kass-Hout brought in. He asked for a form that would

easily allow checking of data that was already entered

into an Access table. This article demonstrates a user

interface for data entry and verification that provides you

with alternative approaches to managing the verification

process using Visual Basic. The scenario is that the user

enters the data twice: once to enter the data and a second

time to confirm that the data is correct.

Data entry user interfaces

When writing a user interface for a data entry specialist,

there are some design criteria that you should factor into

your interface. First, you can safely assume that the

person doing the data entry won’t use a mouse (pop it in

the drawer during the testing phase). Your interface will

consist of plain old text boxes, hot keys, and a maximum

of five buttons. An example of this (really dull) form can

be seen in Figure 1. This form has a number of features

that make it simple for the data entry person. The top

menu offers no unnecessary choices that might excite a

computer programmer (such as database compression or

exporting) but would confuse a user.


The form footer consists of four buttons to enter,

save, navigate, and close the form. This actually makes

keyboard access to the buttons a problem, as you can’t

readily tab from the last field in the form to the bottom

menus. To get around this, we assigned a hot key to each

of those buttons that’s flagged to the end user by an

underline under the character that activates the button. To

program this, open the form in design view and show the

Caption property for your button (see Figure 2). Add an

ampersand (“&”) before the letter that you want to assign

to your button. Now the button can be activated using Alt

keys, and our form has become keyboard-friendly.

Data verification

When Taha and I were developing the software design for

validating data, we came up with a solution that used

table design information and control collections and just a ...




Figure 1. The very simple data entry interface used to input the

initial data.


Read More Here:

Duplicate Data Entry for Access