Hi, Reema.
On Mar 26, 5:08 pm, "'69 Camaro" <ForwardZERO_SPAM.To.
69Cam...@Spameater.orgZERO_SPAM> wrote:
> >I am a new user
> > What are the usability issues for new users in using Microsoft Access
[quoted text clipped - 9 lines]
> "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.
--