I've not run across many "data entry forms" or spreadsheets that are
well-normalized. If you want to get the best use of Access'
relationally-oriented features/functions, you need to provide data in the
structure it expects. Even though the folks are entering the data via a
form, you are not limited to that structure.
If "normalization" and "relational database design" are not familiar terms,
you'll need to spend some time brushing up on them before taking your
database/application to the next level...
Good luck!
Regards
Jeff Boyce
Microsoft Office/Access MVP
those terms are very familiar to me. i've been working with RDBs for
over 15 years. Mainframe, AS400, MS SQL, MySQL, Oracle etc. i am
familiar with the 8 normal forms of normalization - i am not bound by
them, however. even tho i have been trained to do things the *right*
way i have found that *right* is always the most practical way.
the main thing to realize when creating data entry forms is that many
times the data entry employees are short term hires who must be
trained very briefly. the forms need to be designed for 100% hands on
operation and should avoid any unneeded mouse clicks.
the data collected in my case will be analyzed by epidemiologists who
as i said insist that their world is flat. they like to run their own
queries and don't want to look for numbers that link tables to their
data. they want their data.
so depending on the amount of data to be collected - i let them have
their way or not....
when i first had this app dumped on me i was asked to fix a few bugs.
after doing that i mentioned to the POC that it was designed for
crap. i split the data from the client mdb and normalized the
backend. then after futzing with the forms i de-normalized much of it
to facilitate that way all of the actors will be using it.
after thinking about it some moere, tho - i may need to rework the
race bit in my app, however.
