Recommendation for a book: VBA/Access Forms

A

aehchua

Hi all,

I was wondering if someone can help me. I teach a database class at
Nanyang Technological University, Singapore and am looking for a VBA
(Access) textbook to complement the database material I teach. This
book should have the following characteristics:

(1) Preferred: NOT be an introductory programming textbook. All of the
books I've reviewed teach things like variable declaration, arrays,
etc. That's all fine, but my focus isn't there. Too often, authors of
these books are exhausted by the time they finish arrays.
(2) Preferred: By McGraw-Hill. I use a McGraw-Hill database textbook,
and a McGraw-Hill systems analysis and design textbook. If the book is
by McGraw-Hill, the students get a discount on the bundle.
(3) Required: Teach advanced relationships between forms and databases.
Some of the ideas I want include:
(a) The concept of unbound forms. This is a database class. They're
supposed to do SQL things like insert and update. I want a book that
teaches them Select... if rs.eof then insert else update.
(b) time-motion effects. So these would be things like- try not to
force the user to use the mouse because for massive data entry, pure
keyboard is faster. The system should automatically go to where the
user is going to go next. For example, if one is marking examination
scripts, a save should automatically move to the next student.
(c) accomodating reality. Managing level of validity controls,
allowing the user to save temporary data (e.g., on a long form where
the data entry person spots an error. The form should allow the data
entry person to exit gracefully, correct the error and come back to the
form without having to retype everything all over again).
(d) mapping several records to a single form (e.g., like in an invoice
which will have many items). Subforms should be described as ONE
solution and subform solutions should not write directly to the
production database (to maintain the idea of unbound forms). Simulated
arrays (e.g., where form controls are called things like item1 item2
etc.) should be offered as another. Paging algorithms (e.g., the
simulated array has 10 lines. You click on a button to go to page 2
where items 11-20 are displayed) should be described. The idea that a
combination insert and delete is equivalent to an update (makes these
kinds of forms possible to manage).
(e) strategies for handling multiple open windows (e.g., forcing
windows to be modal). I'm not looking at writing complex code as much
as I am looking for strategies by which a programmer can make his or
her life easier when he or she must use multiple windows.
(f) proper screen layout- English speaking people read from left to
right, top-down, so the screen should be like that. Search options
should appear here, data entry should appear here, one should be
disabled if the other is active, etc.
(g) managing the search of composite attributes.
(i) designing screens to both search by and update primary/candidate
keys.
(j) handling multiple users on a single application. This is not
just table and record locking, but also the idea that two people can be
editing the same entries on two different forms. The forms should
alert users to these issues.

In other words, I want a book that gives students a good idea that the
user interface and database often do NOT correspond. I also want a
book that introduces students to the difference between user
requirements, design, and implementation where design/implementation
includes things to make the programmer's life easier.

Cecil Chua
 
A

Albert D. Kallal

(1) Preferred: NOT be an introductory programming textbook. All of the
books I've reviewed teach things like variable declaration, arrays,
etc. That's all fine, but my focus isn't there. Too often, authors of
these books are exhausted by the time they finish arrays.

Well, you can't teach calculus unless your students have good basic math and
algebra skills. The same really applies to ms-access. It sounds like you are
looking to skip the fundamentals, and then you will have egg on your face as
to why students don't understand coding and algorithms. It is a critical
concept that they need. However, some books do much (sadly) skip this stuff.

However, a good book with "real" world samples and applications is:

Microsoft office 2003 inside out (John L. Viescas) - Microsoft press is
quite nice, as it has several "real world" examples.

(a) The concept of unbound forms. This is a database class. They're
supposed to do SQL things like insert and update. I want a book that
teaches them Select... if rs.eof then insert else update.

Teaching users about sql, and then teaching about "recordssets" / eof are
two
HUGE different concepts.

The problem is that ms-access is NOT DESIGNED for un-bound forms. So, you
are suggesting to teach people to use a tool for COMPLETE WRONG WAY. If you
need to teach un-bound forms, then ms-access is THE WRONG TOOL!!!

The problem here is that vb6, or vb.net has a TREMENDOUS AMOUNT OF WIZARDS
and FEATURES to allow developers to build un-bound forms.

With ms-access, if you use un-bound forms, then non of the wizards, or any
of the programming tools support un-bound forms. In fact, with a un-bound
form, then you LOOSE MOST EVERY feature that a ms-access form has.

on.dirty event don't work. (not to mentioned the me.dirty flag is of no use)

before update, after update events don't work

on current event dont work/fire.
on insert, after insert events don't fire (these events are critical for
settup defauls and foright key
values in a reocrd).

An un-bound form means that
these events don't fire, and are of NO USE!!!

Worse, is all of the data validation, and even the deleting events do not
work. That list of events is HUGE. Some of the events are "on undo", "on
delete", "Before del confirm", "after del confirm". All of these AMAZING
events are there because they SOLVE the problem of having a bound forms.
These events allow you to use a bound form with very good data valadiation.
If you use un-bound form then a HUGE LIST OF access featuers are of NO use.

So, what this means is that you get the WORST of both worlds.

ms-access has no features and wizard support for un-bound forms.

Worse, the programming enviorment is NOT designed around a un-bound
form, and thus you have to start coding all of these events by yourself.

You are MUCH better to use vb6, or some other product that SUPPORTS and is
FULLY DESIGNED AROUND a un-bound forms object model.

With systems designed around un-bound forms, then you have a data object
that you can place on the form, and attached the controls to that. It is a
complete DIFFERENT approach. Note that vb6, Delphi, vb.net tools all use
this
approach AND HAVE SUPPORT FOR THIS approach.

The reason why you can't find a book teaching you to use un-bound forms in
ms-access is because it is like cutting the grass with a pair of scissors
when a nice lawnmower is sitting in the garage.

Worse, since ms-access is NOT designed for un-bound forms, then the students
WILL NOT LEARN HOW TO USE un-bound forms correct. For example, be it Delphi,
vb6, or even vb.net, when you build data forms, they have a concept of a
data control, and a process for connection fields to that data control.
Ms-access does not have anything remote like this concept (and, worse, as
mentioned, no wizards, no code support, no events support.no nothing that
works well with unbound forms).

So, not only will the students find this an
exercise in sillyness, but in fact the WILL NOT LEARN HOW to use systems
that built around a un-bound forms model. So, if you tyring to teach these
people how systems with un-bound forms work, ms-access is the WRONG TOOL!!!

Those other systems work WELL with un-bound forms because they have all of
the programming and data connection features built in to SUPPORT THE WHOLE
CONCEPT of un-bound forms. Ms-access does not have that same support built
in. So, you are barking up a the wrong tree here.
(b) time-motion effects. So these would be things like- try not to
force the user to use the mouse because for massive data entry, pure
keyboard is faster. The system should automatically go to where the
user is going to go next. For example, if one is marking examination
scripts, a save should automatically move to the next student.

Now you talking about UI issues. It can take a long time to learn these
kinds of things. If you teach people not to frustrate users, then with their
brains they should then figure out that reducing the dance between keyboard
and mouse is a obvious conclusion.

There is a free on line book for user interface stuff here, and it apples to
vb.net, or ms-access, or anything you use.

The ui link is here:

http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

(there is also a printed edtion).

Perhaps you simply want to touch on that making a application work well via
the keyboard is a good idea (but, that is a simple one sentence, and we are
done!!).
(c) accomodating reality. Managing level of validity controls,
allowing the user to save temporary data (e.g., on a long form where
the data entry person spots an error. The form should allow the data
entry person to exit gracefully, correct the error and come back to the
form without having to retype everything all over again).

With ms-access, you have an INCREDIBLE amount of forms events. You just have
to learn those events. If you talking about un-bound forms again, then as
mentioned, you using the wrong tool, and using a tool for purpose other then
its designed for will simply only confuse people. In fact, using un-bound
forms is actually LESS productive in ms-access then those there systems
with features that support un-bound forms.
(j) handling multiple users on a single application. This is not
just table and record locking, but also the idea that two people can be
editing the same entries on two different forms. The forms should
alert users to these issues.

Actually, the forms do show you when a record is locked by other users
(well, bound forms do!!!). More important is
to teach people the difference between an application part, and a data part.
The key concept in ANY multi-user application in ms-access is to split your
database. I have an article here on this:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

Note that the above article does not just tell you to split, but TELLS YOU
WHY you split. It also explains that ms-access is NOT a database, but
is a tool like vb6, or vb.net.
In other words, I want a book that gives students a good idea that the
user interface and database often do NOT correspond.

That is correct, but then again, why would you then use ms-access to teach
users about un-bound forms when ms-access DOES NOT include any decent tools,
wizards, documentation, or even features that support un-bound forms?

With bound forms, there is a HUGE amount of events and learning that takes
place in ms-access. This is a question of the right horse for the right
course. I would not suggest or use ms-access to teach un-bound forms. They
just are not supported well at all.
I also want a
book that introduces students to the difference between user
requirements, design, and implementation where design/implementation
includes things to make the programmer's life easier.

That is a tall order.

You not going to find, or fit your kinds of requirements into a book.....you
talking about a whole computing library!!!

However, a great introduction and one that comments on the use
of functional specification document is here:

http://www.joelonsoftware.com/articles/fog0000000036.html


And, while you are at it, you might as well touch on the difference between
a functional specification,and a technical specification.
 
L

Larry Linson

I do not know of a book that meets your requirements in one volume.

A good book is "Designing Effective Database Systems" which deals with
relational principles, and with application design. It is written by Rebecca
Riordan, published by Addison-Wesley, ISBN 0-321-29093-3.

And book with many advanced VBA examples, concensus choice of most Access
professionals, is the Access Developer's Handbook, by Litwin, Getz, et al,
published by Sybex -- the name will vary slightly depending on the version
of Access addressed, for example, the desktop edition for Access 2002 is
"Access 2002 Desktop Developer's Handbook," by Paul Litwin, Ken Getz, and
Mike Gunderloy, published by Sybex, ISBN 0-7821-4009-2. (There was
relatively little Access-specific change between Access 2002 and 2003, so
there is no edition for Access 2003 -- but I am expecting to see one for
Access 2007!)

You aren't going to find many Access books that recommend unbound forms.
And, because Access Forms and Reports use tables, queries, or SQL statements
as their RecordSource, I'm not certain it is as important as you might
think. But, bound forms are the recommendation of every experienced,
professional Access developer because they are efficient, quicker and
simpler to develop, and handle a lot of details for you.

Larry Linson
Microsoft Access MVP
 
A

aehchua

Albert D. Kallal wrote:

<snip>

Hi Albert,

For clarification. I am trying to get past the programming and teach
User Interface development (UID). We've got programming courses at our
university. That's why I don't want a programming book. I want a book
that teaches UID concepts, and uses VBA to illustrate those concepts.

I also want to teach students using the tools they have handy, and I
don't want to spend my time working with students as they download
various tools (which is why I'm not doing this with Open Office/a Java
GUI/whatever). The idea is that students can listen to me, read a
book, go home and do their projects. Students should only visit me
with problems related to the course content, not "I can't seem to get
whatever config file working. Can you help me?" I can be 99% certain
that any student in my class has access to MS Access, and that the
install is working. I don't have that level of guarantee with any
other development tool.

I agree it could all be done better in Visual Studio. Most folks don't
have it. Most folks have MS Access on their machines. We could go the
MSDNAA route, whereupon Visual Studio becomes a free download.
However, my school hasn't gone that route. Plus, I don't want to deal
with configuration issues.

As a side note... I really don't see how recordsets (resultsets,
whatever the language wants to call them) can be omitted from SQL
instruction. Most IT majors will write their SQL inside some kind of
application code. They need to know how to manage ODBC/JDBC/Name your
interface standard or at least the principle logic by which these
standards work.

Cecil Chua
 
A

Albert D. Kallal

For clarification. I am trying to get past the programming and teach
User Interface development (UID). We've got programming courses at our
university. That's why I don't want a programming book. I want a book
that teaches UID concepts, and uses VBA to illustrate those concepts.

Ok, at least we are now trying to narrow down where you are going here.
We could go the
MSDNAA route, whereupon Visual Studio becomes a free download.

The "express" versions of sql server and even visual studio (.net)
are free downloads..and have been for quite a awhile now.
No special licensing is needed...

You can find them here:

http://msdn.microsoft.com/vstudio/express/

You have web based stuff, sql server express...all of that stuff is free
now...
As a side note... I really don't see how recordsets (resultsets,
whatever the language wants to call them) can be omitted from SQL
instruction.

I can. If you are teaching sql, and database normalizing, then
reocrdsets will not be at issue at all. Again, are we
teaching sql, and how that works? Or, are we teaching users
to use some reocrdset object model?

Also, if you are
teaching UI development, then again reocrdsets have little, or
nothing to do with UI, or the application design and
development process.

Of course, if you are expanding on what you are trying to teach, then
sure, a instruction to the concept of reocrdsets makes sense, but
then again, I not sure if that needs to be tied to "user interface"
programming lesson? Or a lesson on the application development
cycle?

As I noted, I gave a link to some user interface stuff. And, I even
have an article here that uses ms-access:

http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm

While the above teaches a few concepts of UI (and happens to use ms-access),
you
see that the concepts explained for good UI had nothing to do with coding or
VBA recordsets.

Further, while you can find some articles and things on functional specs (I
gave a few links), it is doubtful that
you would find such a book written for use via VBA, further mixed in with
that subject is the development cycle. and, further to that
a UI design primer. And, further to that would be writing technical specs
(that is the stuff you give to the developers to code!!).

I guess I just a bit surprised that the long lists of demands that you seem
to think is no problem to fit into a single book..and nothing could be
farther from the truth.

Also, as I pointed out, you questioned why there is a lack of information on
how to use un-bound forms in ms-access, and I simply explained why this is
so. You seemed to hint that this is how development is done in ms-access,
and again I had to set the record straight. So, if these people learn this
on ms-access, they better be taught that this is not how the tool is
normally used, or even should be.

Last, but not least, a course that walks people though a typical development
process for an application is most certainly a sensible, and great idea. So,
I don't want to throw bath water on your quest here. I actually think a
book with some good "requirements" gathering lessons, and then turning those
requirements into a functional spec would be great. You then take the
functional spec, and turn it into a technical spec for ms-access. You then
have the people do the coding and work based on that technical spec.
 
J

Jamie Collins

ms-access is NOT DESIGNED for un-bound forms.

you are suggesting to teach people to use a tool for COMPLETE WRONG WAY.

ms-access is THE WRONG TOOL!!!

you LOOSE MOST EVERY feature that a ms-access form has.

these events don't fire, and are of NO USE!!!

all of the data validation, and even the deleting events do not work.

a HUGE LIST OF access featuers are of NO use.

you get the WORST of both worlds.

you have to start coding all of these events by yourself.

it is like cutting the grass with a pair of scissors

ms-access is NOT designed for un-bound forms

no wizards, no code support, no events support.no nothing that works well

an exercise in sillyness

ms-access is the WRONG TOOL!!!

you are barking up a the wrong tree

Albert,
Stop dithering. Come down off the fence and make your mind up. Unbound
forms in ms-access: yes or no?

[with tongue firmly embedded in cheek]

Jamie.

--
 
J

James A. Fortune

Larry said:
You aren't going to find many Access books that recommend unbound forms.
And, because Access Forms and Reports use tables, queries, or SQL statements
as their RecordSource, I'm not certain it is as important as you might
think. But, bound forms are the recommendation of every experienced,
professional Access developer because they are efficient, quicker and
simpler to develop, and handle a lot of details for you.

Larry Linson
Microsoft Access MVP

I'm not certain bound forms are as important as you might think. Access
supports the use of both bound and unbound forms. Access developers are
free to choose whichever technique fits their purposes. I use a lot of
unbound forms in Access to minimize the possibility of corruption since
I have lots of simultaneous users (> 100) and don't always agree that
the leveraging of bound forms to cases that are naturally unbound, such
as address updates where the last edit is the most correct, is worth the
risk. Besides, working with unbound forms is more easily scaled to
environments that some would suggest are more, dare I say, professional.
I agree that leveraging bound forms buys you a lot, but don't agree
that you should throw out the Access baby with the bathwater if you need
few or no bound forms. A SQL Server backend eliminates most, if not
all, of the corruption risks, but if you eventually go browser-based is
there a way to have forms bound to data? Would that even be a good
idea? I don't disagree with the recommendations of those pros because
they have definite reasons for using bound forms. Those reasons don't
apply in every situation.

James A. Fortune
(e-mail address removed)
 
A

aaron.kempf

dont give a shit about Access forms learn SQL Server, newbie

MDB is for ****ing retards.
Use Access Data Projects if you must.. or ASP / Dreamweaver or
something.

MS has wasted these past 5 years

-Aaron
 
T

Tony Toews

James A. Fortune said:
I'm not certain bound forms are as important as you might think. Access
supports the use of both bound and unbound forms. Access developers are
free to choose whichever technique fits their purposes. I use a lot of
unbound forms in Access to minimize the possibility of corruption since
I have lots of simultaneous users (> 100)

I'm not at all sure I agree with your reasoning here.After all Access
only writes the record twice when doing inserts and once when doing
updates. What does it matter that Access is doing this from a bound
form or from within code?
Besides, working with unbound forms is more easily scaled to
environments that some would suggest are more, dare I say, professional.

How so?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
G

Guest

Another one of Viescas' books is also excellent for showing students (and
professional developers) examples of complete applications (4). Check out
John's "Building Microsoft Access Applications" from MS Press.

LDN

PS 1
If you find a single book that meets all your criteria, please let the rest
of us know what it is.

PS2
I am waiting to see my first example of a complete Access application that
blows my socks off, one that screams out, "This person/team really knows
Access development."
 
T

Tony Toews

Tony Toews said:
After all Access
only writes the record twice when doing inserts

I should clarify that. Access writes an empty record with the
autonumber present when you hit the first key stroke on a bound form.
Then when the record is updated it updates all the fields.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
J

James A. Fortune

Tony said:
I'm not at all sure I agree with your reasoning here.After all Access
only writes the record twice when doing inserts and once when doing
updates. What does it matter that Access is doing this from a bound
form or from within code?

I'm only speaking from experience. The chance of corruption seems to go
up as the number of bound forms increases. That is, unless Samba is
used. That is because I have no data for corruptions using Samba even
with bound forms due to the fact that I never got a single corruption
with that setup. My theory about the write time is only speculation and
the lack of corruption may be entirely due to the superior robustness of
linux over windows.

A SQL Server backend eliminates most, if not all, of the corruption
risks, but if you eventually go browser-based is there a way to have
forms bound to data? Would that even be a good idea?

James A. Fortune
(e-mail address removed)
 
A

aaron.kempf

Data Access Pages are an awesome way to have simple client-side
binding.

they work GREAT against Access Data Projects.

I usually have an ASP wrapper around a DAP; I don't like changing the
DAP definition; it's not the most stable.

I usually use Access to butcher a DAP into a single grid.. and then
include it inside a normal ASP page.

-Aaron
 
T

Tony Toews

James A. Fortune said:
I'm only speaking from experience. The chance of corruption seems to go
up as the number of bound forms increases.

I'd agree with the chance of corruptions going up with the number of
users. But not with the number of bound forms.
That is, unless Samba is
used. That is because I have no data for corruptions using Samba even
with bound forms due to the fact that I never got a single corruption
with that setup. My theory about the write time is only speculation and
the lack of corruption may be entirely due to the superior robustness of
linux over windows.

But I've seen so few corruptions I can't say I have a lot of personal
experience. However I've read just about every posting on corruption
on the MS newsgroup servers.
A SQL Server backend eliminates most, if not all, of the corruption
risks,

Sure but SQL Server has nothing to do with bound forms.
but if you eventually go browser-based is there a way to have
forms bound to data? Would that even be a good idea?

There are DAPs but they are deprecated and require each user to have
some kind of license so only suitable on an Intranet.

You'd have to use different technologies for web based apps.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
M

MPAPoster

Tony said:
I'd agree with the chance of corruptions going up with the number of
users. But not with the number of bound forms.

The chance of corruptions going up with the number of users is nearly
always because of bound forms. I believe that it's possible for an
unbound form to cause corruption, but I have never seen it happen.
BTW, the few corruptions I have seen caused by bound forms that were
not caused by someone pulling out a network cable on the server went
away as soon as the network speed improved.

James A. Fortune
(e-mail address removed)
 
A

aaron.kempf

DAPs live on OWC and OWC is 'guaranteed support until the end of 2013'
at least

that's a lot longer than it sounds-- go ahead and build it for the next
10 years; you might miss another TWO GENERATIONS OF CRAP FROM MICROSOFT

and I think that Microsoft will again embrace COM and we can write
against a compatable GUID.

OWC is the panacea; the most important development for intranets since
the release of Netscape Navigator

PivotTables against Analysis Services, in a web format?

it's impossible to top.... it's the best reporting platform in the
world.

-Aaron
 
A

aaron.kempf

and by the way Tony, if you haven't personally seen a dozen cases of
MDB corruption then you're not pushing the envelope.

I've had MDB corruption for at least a dozen clients; I rewrite
everything as a simple ADP.. I mean.. RIGHT-CLICK <IMPORT>

-Aaron
 
T

Tony Toews

The chance of corruptions going up with the number of users is nearly
always because of bound forms. I believe that it's possible for an
unbound form to cause corruption, but I have never seen it happen.
BTW, the few corruptions I have seen caused by bound forms that were
not caused by someone pulling out a network cable on the server went
away as soon as the network speed improved.

Well, I still respectfully disagree. I can't see why there would any
difference between bound and unbound forms when it comes to
corruptions.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
A

aaron.kempf

it's a question of DAO vs ADO.

bound forms use some DAO _CRAP_ internally.. don't they?

with ADO and unbound forms you're guaranteed stability

Personally; I wouldn't touch unbound with a 10 foot pole.
of course; I wouldn't touch MDB with a 10 foot pole either

-Aaron
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top