Let me correct one of the points in your post first: I work for a living
separate from the newsgroups and the advices given in these newsgroups are
*free* and *of my own free will*. MVPs and other respondents don't earn any
money from these newsgroups!
In your original post, you wrote "...but humor me for now" regarding the
Table Structure so I did. However, 2 out of 3 replies (the 3rd replies only
for a specific point) referred to the properly-designed Table Structure.
Note that I didn't use "consolidate" or "combine" like you did since there
are rules that need to be followed to have an efficient and flexible Table
Structure. Access can handle a properly-designed Table with 100K+ Records
with no problems but it will not work efficiently with 7 of Tables with 1000
Records each or other incorrectly-structured Tables.
*In humoring you* with your "7 Tables of similar structure" + "to edit those
records via the form using the query and leave the records in their own
tables", I suggested using a Make-Table Query to make a *temp* Table but I
do hope you take into account of what I wrote after that. I am not sure
whether you objected to this temporary Table or your impression that I
implied "consolidating" or "combining" 7 Tables into one Table (which I did
not!). If you meant the temporary Table, then please re-read what I wrote
in the same point. Of course, I don't have these problems in databases I
design and earn my living from.
In making any program as simple as possible for the users, I am not sure
whether you referred to making your database, with you as the developer, as
simple as possible for your computer novice users or the Access software
making as simple as possible for you as the user so I'll address both.
If the former, it is then even more important to get the Table Structure
correct and then to design easy and intuitive GUI for your users. However,
the second aim(easy and intuitive GUI) cannot be achieved easily without the
first (correctly-designed Table Structure). Sure there are people who can
simply use their logical mind and their common sense to do this but most of
us will need to understand the Relational Database Design Principles (and
know how to apply the Database Normalisation technique). IMHO, database
developers that don't know RDDP and Normalization do a *disservice* to their
clients.
If the later, sure Access does a hell of a good job for everyone to create a
database by throwing a bunch of Tables / Queries / etc... together. Users
can do a lot with basic knowledge of how Access works and how to put a few
things together. In fact, this is why I.T. profesionals / developers with a
cursory glance at Access ("Yeah. It's part of the Microsoft Office suite
for 'users'.", I hear.) tend to consider Access not as "developer's tools".
However, like most other software, we need to invest time to get the best
out of the software. In Access, we need the additional effort to know about
RDDP + Normalisation. Just think of reading a 100-page Access book and a
1500-page Access book: they could not simply have the same content even
though they both show the readers how to create "databases".
Another example: I once tried to write a Mathematics paper in Word using a
template for numbering / indexing / footnotes / etc and mathematical
symbols, e.g. the integration sign of the stretched capital S ("Other
people could do it; sure I could do it easily since it is only Word,
anyway." mentality). How wrong I was! I finished the paper after spending
inextrodinary amount of time on Word that I thought was designed for average
users and simple to use.
I wrote all of these as matter-of-factly and meant no harshness. My advices
in these newsgroups are free (I stress) which you are free to heed or not.
Since I already mention RDDP + Normalization (which is the cure) a number of
times so I think I stop here.
--
HTH
Van T. Dinh
MVP (Access)