ma*******@rogers.com (Martin Lacoste) wrote in message news:<d4*************************@posting.google.c om>...
Wondering if people have suggestions as to good reference sources for
Access 2000 for an (almost..) intermediate user? It appears as
though books along the lines of 'Access for Dummies' are way too basic
for my needs. Or would I be best to continue to root around the
internet and this newsgroup? I really would like a book I can refer
to, however...
To give a better idea as to the level I'm looking at..
- queries are generally not a problem (though not terribly efficient,
I'd guess)
- macros - ok
- modules and VBA - have done a little here
But, and excuse my ignorance, I still have a heck of a time
differentiating between the various 'levels' of programming (ie. when
should one use a query vs. a macro vs. a module vs. VBA..etc..). I'd
like a resource that clearly defines and delineates the possibilities
and limits of each approach. Modules still confuse me in terms of how
they function within Access, and I even made some that worked!! A
clear and comprehensive resource that I can keep going back to when my
memory fades would be my wish!!
Any help is greatly appreciated!
Thanks!
Martin Lacoste
Here are some observations I have about my style in Access. YMMV.
Tables - In a typical app over half the tables in the front end are
linked. The ones that are not linked are tables that do not change or
that control things for the individual user yet can be overwritten
when updates are available. I sometimes link to as many as five
backend databases from one front end.
Queries - In spite of the speed benefit from using predefined queries,
my use of them is falling off rapidly. Context dependent SQL strings
are more flexible. Plus, I don't have to keep track of which forms
and reports use which queries.
Forms - I try to avoid subforms due to problems they cause in
converting apps to compiled versions but users can't get enough of
them. I hide the tables and make users use forms. I usually have
about twice as many forms as tables. Except for subforms I rarely
call the code behind one form from another.
Reports - I have about as many reports as tables. Users are not
usually allowed to open reports directly. They are forced to open
them from forms. Since the people who sign my checks view Reports as
what the software does, I will be placing increasing emphasis on
Reports. As I get better at creating PDF reports from Access I will
rely less on these.
Macros - All the macros I've ever written in Access are named
AutoExec. When I do use an AutoExec macro it is only to open a form
or to run code from a module. The name is a little confusing since
Access macros don't record a series of actions.
Modules - The code in modules tends to be general purpose. Code in
modules form a one to many relationship with Form/Report calls :-).
An example of modules for one of my projects would be modAPIFunctions,
modDomainFunctions, modFontFunctions, modFunctions, modGlobal,
modPDFFunctions and modStringFunctions.
So I see Access development in the near future for me as:
Design the tables keeping usage in mind
Build the forms using as much cut and paste as possible
Get feedback from users
Design the reports
Get feedback from management
Reuse most of the module code
Later on I see it as:
Design the tables keeping usage in mind
Run forms that design forms and that create code behind them
Fine tune the automatically created forms
Get feedback from users
Run forms that design reports and that create code to manufacture them
Fine tune the automatically created reports
Get feedback from management
Reuse most of the module code
Maybe this will help in differentiating between approaches. There is
still a lot of art to database programming. I hope you find a book
that does all that defining and differentiating of the possibilities
and limitations in a clear and comprehensive manner that is
appropriate to your level of programming (whew!). Strive to
understand the users' needs and the best way to satisfy them.
James A. Fortune
....measuring end-user attitudes. Some of these techniques are
user-centered design oriented and aimed at providing early design
input through analysis of user responses... --- C. Stephanides
User Interfaces for All