Handling Bugs

[David W. Fenton]

Compiling is certainly necessary, but it is not sufficient.
You still have to guarantee that all referenced libraries
are the same on the compiling machine and on all the client
machines. IME, different clients insisted on their own idea
of the "correct" set of libraries so there was no reasonable
way for my machine's libraries to match up. This led me to
adopt the (questionable?) practice of taking a decompiled
program to the client's and doing the final compile on site.
If any client did not manage their systems well enough to at
least have the same libraries on all their machines, then it
was their problem.

I think that you really oughtn't need to do that if you use late
binding for everything but the default Access libraries. The only
thing that would then cause it to fail would be something like the
DAO DLL not being registered, and compiling on that machine wouldn't
fix that, in any case.

 

[David W. Fenton]

Let me know a little bit more about the problem of libraries if
you would - - and anyone else can join in if need be.

If you're distributing on Win9x, then you're obviously using A2K or
earlier. The key thing about MDEs failing is the question of
references, which can't be fixed up on the fly in an MDE. Because of
this, as I said in my reply to Marsh's post, I use late binding for
everything but the default Access references. This means that the
only references any of my Access databases have in them are:

Visual Basic for Applications
Microsoft Access X.X Object Library
Microsoft DAO X.X Object Library

In the case of Access 2007, the DAO library is called something else
now (ACE?), and the X.X will differ according to the version of
Access, e.g., for A2K, it's Access 9 and DAO 3.6, for A2K, Access 10
and DAO 3.6 and for A2K3, Access 11 and DAO 3.6 (noticing a
pattern?). Any other libraries, such as the Office Automation
library or JRO or any of a number of others I get rid of the
reference and use late binding.

Late binding means that your code doesn't have any compilation
dependencies on that outside libary that you're using through late
binding. It also means it's possible to recover from the absence (or
misconfiguration) of the outside component.

Search the Access newsgroups on Google Groups for the phrase "late
binding" for lots and lots of posts on the subject. It's a tool that
anyone distributing a runtime app really needs to use regularly,
particularly given diverse target systems.

 

[Frank Wagner]

David and Marshall:

I use Access 2000, and all the code is ADO. I have not made any library
references except what comes standard with Access 2000. Does that help any?

 

[Frank Wagner]

Marshall:

See my response to David. Does this help?

 

[Allen Browne]

Responses in-line.

I understand you comments about error handling, and will be working on
making sure errors are logged as a part of the system. Thanks for leading
me to the code for doing that. One question I had is how do you capture
the name of the calling procedure?

Unfortunately, VBA does not expose the name of the currently-executing
procedure.

MZTools will drop the proc. name in for you.
For a place-holder, use:
{PROCEDURE_NAME}

The other piece of the puzzle is the module name. Module.Name fails in an
MDE. Me.Name doesn't work for stand-alone modules. What I do is to declare a
private constant of the same name in the General Declaration section of
every module, e.g.:
Private Const conMod = "Module1"
I can then use conMod in the code that calls the generic error handler, so
it receives the name of the relevant module. And if you cut/copy'n'paste to
another module, there's nothing to change (i.e. it still reports the correct
module.) So, the error handler template I use in MZTools is:

'On Error GoTo Err_Handler
'Purpose:
{PROCEDURE_BODY}

Exit_Handler:
Exit {PROCEDURE_TYPE}

Err_Handler:
Call LogError(Err.Number, Err.Description, conMod & ".{PROCEDURE_NAME}")
Resume Exit_Handler

(Note that this inserts the error handler commented out until I get the
procedure debugged.)

Focus control is one thing that drives me crazy. Do you know of any good
source of information for me to study? One problem that haunts me is when
a student enters the wrong answer, the focus doesn't want to return to the
same answer control even if I instruct it to with the "Set Focus" command.
I have to jump through hoops to get it back to the same spot.

David Fenton's reply explains how cancelling the control's BeforeUpdate
event keeps focus there until you get a valid entry. That's the best
approach.

Having said that, this is something I use only rarely. Mostly, I prefer to
do all the validation in Form_BeforeUpdate. I think people find it less
annoying if they get the chance to fix a silly thing themselves, and only
handle one message box if things are not right. (Additionally,
Form_BeforeUpdate is the only event to compare fields, and to test for
nulls.)

By the way, my daughter attended the University of Notre Dame branch
in Perth a number of years ago. She loved the area. It's beautiful.

Wow. Yes, it's a very enjoyable city. Thanks.

 

[Frank Wagner]

David:

Since I only use the default libraries does that mean that late binding is
not necessary?

If it is necessary, I'm afraid you'll have to explain it to me a little
more. If that means compiling on the clients site, I'm afraid that wouldn't
work in my case.

Thanks

 

[Rick Brandt]

David:

Since I only use the default libraries does that mean that late binding
is not necessary?

If it is necessary, I'm afraid you'll have to explain it to me a little
more. If that means compiling on the clients site, I'm afraid that
wouldn't work in my case.

Thanks

If you only use the default libraries then you should have nothing to
worry about and nothing extra you need to do.

 

[Marshall Barton]

I think that you really oughtn't need to do that if you use late
binding for everything but the default Access libraries. The only
thing that would then cause it to fail would be something like the
DAO DLL not being registered, and compiling on that machine wouldn't
fix that, in any case.

Good to hear that from someone with your experience, David.
Thanks for clarifying the runtime scenario.

 

[Frank Wagner]

Albert:

Thanks to you and everyone else who has helped me. I think I've got a
direction now that I can proceed with.

Thanks Again

 

[Frank Wagner]

Marshall:

Thanks to you and everyone else who has helped me. I think I've got a
direction now that I can proceed with.

Thanks Again

 

[Frank Wagner]

David:

Thanks to you and everyone else who has helped me. I think I've got a
direction now that I can proceed with.

Thanks Again

 

[Frank Wagner]

Allen:

Thanks to you and everyone else who has helped me. I think I've got a
direction now that I can proceed with.

Thanks Again

 

[David W. Fenton]

Since I only use the default libraries does that mean that late
binding is not necessary?

Depends on what you mean by "default libraries." I often see Access
add in an Office Automation library and compatibility libraries when
I upgrade, and these are completely unnecessary to any of my apps.
As I said in my other post, the three base references are all I ever
have in any of my apps. Any other library that I use, I use via late
binding, with no reference.

 

[David W. Fenton]

I use Access 2000, and all the code is ADO. I have not made any
library references except what comes standard with Access 2000.
Does that help any?

Well, right away I see a problem in using ADO, which is not
something I consider to be native Access. If your back end is SQL
Server, perhaps it makes sense, but if it's Jet, then using ADO is
really not justifiable in any way, in my opinion. MS wanted you to
*think* you should use ADO with Jet, but they were mistaken -- it
was always a silly idea.

 

[David W. Fenton]

in re: control's BeforeUpdate event

Having said that, this is something I use only rarely. Mostly, I
prefer to do all the validation in Form_BeforeUpdate. I think
people find it less annoying if they get the chance to fix a silly
thing themselves, and only handle one message box if things are
not right. (Additionally, Form_BeforeUpdate is the only event to
compare fields, and to test for nulls.)

I think it makes sense to validate entry when it's happening. That
means choosing an appropriate control type in the first place. If a
field can only have a limited number of values, an option group or a
combo box or listbox are the appropriate control type.

If it's a date field, Access date handling will prevent the entry of
an invalid date, but it won't prevent you from entering nonsensical
dates (such as 12/15/208 instead of 12/15/2008). For that, you can
use an input mask or logic in the BeforeUpdate event. I have
something of a love-hate relationship with input masks -- I hate
them myself, but users don't seem to mind them at all, since they
take away any need for them to think about what they are supposed to
enter.

I wouldn't leave something like that to a form-level event. Indeed,
I wouldn't leave cross-field comparisons to a form-level event,
because I think it's extraordinarily annoying to enter a bunch of
data and then after your focus has moved on from entering each piece
of information, to be informed of an error in the data. Say you're
entering data from a paper form. If you get the validation message
at the time you enter one piece of data, you should immediately be
able to scan back to the exact same location on the paper form to
check what you should have typed. If the validation is left to the
end, you have to rescan the whole page and relocate each individual
piece of data.

I can see situations where groups of fields should definitely be
validated together, but in that case, I'd like use a wizard-type
interface, with data fields entered in small groups, with <<Previous
and Next>> buttons, and the Next>> button would not be enabled until
the data in the current set of fields is valid and internallly
consistent.