this is a
peer-to-peer newsgroup for Microsoft Access database questions where folks
ask "How do I . . . ?" or "Why doesn't this work the way I expected it to?"
or "Where would I find more information on . . . ?" and other folks try to
answer those questions or give advice based upon their own experiences of
what works and what doesn't.
If ... you need help making Access more
"usable" in your opinion, please state which task you are having difficulty
with, and we'll try to offer suggestions.
I read this group via Google Groups where it is billed as a
"discussions" group. I think it is only Microsoft's 'Office Online'
that tries to make it a Q&A for MVPs. The OP's subject sounds to me
like a good topic for discussion, although of little interest to me
personally and I suspect it will be widely seen as an unpopular one.
By asking this question in the newsgroups,
you'll likely only get subjective opinions, such as "There _are_ no
usability issues in Access, because everyone can use Access, even without
training."
Agreed.
Here's an angle for the OP: Access is a cul-de-sac.
It is a member of the family of SQL products but it is the black sheep
because it breaks the rules, does things differently, has its own
terminology for things that are standard (e.g. the term 'query' is
multifaceted) and even tries to shield users from the engine and even
from SQL itself. It is said that one must spend considerable time
'unlearning' Access when moving to another SQL product. Moving from
another SQL product to Access is so painful that most do not bother.
Take its forms engine, for instance. It is different from other forms
engines, more like an interactive reports really, so skills aren't
transferable from/to other Windows programming languages and may even
be a hindrance (i.e. a skills lock-in). Bound forms are the norm, RAD
being the very essence of Access. The unit of work for a bound form is
the field (i.e. change an attribute and it gets immediately written)
but in SQL the minimum unit of work is the row, an obvious impedance.
On the other hand, the engine ('Access' meaning a Jet data store, of
course) has no trigger mechanisms and is capable of executing only one
SQL statement -- sorry! -- 'Action Query' per operation (e.g. no
control of flow). Consequently, 'front end' forms are the preferred
location for implementing tasks that are better suited closest to the
data i.e. in the 'back end' (data integrity constraints, stored
procedures, etc) even though this is contrary to good software
principles e.g. tier architecture.
As I say, just something to set to ball rolling.
Jamie.
--
