Error Message different in MDB and MDE

[david epsom dot com dot au]

In an MDB, an unhandled error in a form event gets a VB msgbox, with a VBA
error message.

The same unhandled error in an MDE gets an Access msgbox, with an Access
error message.

To my surprise and disgust, the production copy of my database behaves
differently than my development copy.

For those who are interested, I have tested with a simple error in the click
event of the detail section of a form:

Private Sub Detail_Click()
Dim i As Integer
i = i / 0
End Sub

In the MDB version, I get an error message like this:
Microsoft Visual Basic
Run-time error '6':
Overflow

In the MDE version, I get an error message like this:
My Application Name
The expression On Click you entered as the event property setting
produced the following error: Overflow.
The expression may not result in the name of a macro, the name of a user
defined function, or [Event Procedure].
There may have been an error evaluating the function event or macro.

Since the MDE version is an Access MsgBox, the first section of the message
is bold.
Also, although you can't see it in this example, it discards err.description
and uses it's own description of the error.

For comparison: If you use an error handler with a msgbox, you get this:
Microsoft Access
Overflow

Which is Err.Description in a VBA msgbox with the caption incorrectly
supplied by Access.

 

[pieter wijnen]

Allways test your app with the /runtime switch before you deploy ;-)

Pieter

"when everything else fails blame Bill"

 

[Albert D. Kallal]

In an MDB, an unhandled error in a form event gets a VB msgbox, with a VBA
error message.

The same unhandled error in an MDE gets an Access msgbox, with an Access
error message.

To my surprise and disgust, the production copy of my database behaves
differently than my development copy.

Well, the mde is a "compiled" version with all of the VB source code striped
out. The ide can't jump to the bad line of code in question.

Further, what is VERY useful in this case is that a un-handled error in a
mde DOES NOT re-set all global vars. So, in the many routines that don't
have any error handling, a un-handled error will NOT blow out all global
(and local) vars. If you encounter an error in a mdb, then ALL YOUR vars
(both local, and global) are re-set.

So, yes, the final compile production version (your mde) that you sent out
to users will behaving somewhat different, and in most cases it will behave
MUCH better (such as variables not being re-set when an error occurs). For
this reason, I have always distributed a mde to my users, and have enjoyed a
more reliably setup as a result.

Of course, the real final solution is to use error trapping and give your
own message, or deal with the problem....and that will work the same in both
cases.

So, I not too surprised that running a mde with all source code stripped out
results in somewhat different behaviors then using the mdb with source code.

Obviously, working with the VBA IDE, and source code editing is intended for
developers, and your final production mde is intended for users. We can't
expect, nor want users to jump into the VBA code to look at things.

So,
mde = production version for users
And,
mdb = version with source code and VBA editor for developers.

In effect, a mde is the equivalent of a .exe for access developers.

 

[david epsom dot com dot au]

Always test your app with the /runtime switch before you deploy ;-)

No, the runtime behaviour is different, /and is documented incorrectly/.
In the runtime environment, an unhandled error closes the application -
if the application is an MDB. This is the documented behaviour. If the
application is an MDE, we get the undocumented behaviour I am describing,
regardless of the runtime/retail environment.


(david)

Allways test your app with the /runtime switch before you deploy ;-)

Pieter

"when everything else fails blame Bill"

In an MDB, an unhandled error in a form event gets a VB msgbox, with a VBA
error message.

The same unhandled error in an MDE gets an Access msgbox, with an Access
error message.

To my surprise and disgust, the production copy of my database behaves
differently than my development copy.

For those who are interested, I have tested with a simple error in the click
event of the detail section of a form:

Private Sub Detail_Click()
Dim i As Integer
i = i / 0
End Sub

In the MDB version, I get an error message like this:
Microsoft Visual Basic
Run-time error '6':
Overflow

In the MDE version, I get an error message like this:
My Application Name
The expression On Click you entered as the event property setting
produced the following error: Overflow.
The expression may not result in the name of a macro, the name of a user
defined function, or [Event Procedure].
There may have been an error evaluating the function event or macro.

Since the MDE version is an Access MsgBox, the first section of the message
is bold.
Also, although you can't see it in this example, it discards err.description
and uses it's own description of the error.

For comparison: If you use an error handler with a msgbox, you get this:
Microsoft Access
Overflow

Which is Err.Description in a VBA msgbox with the caption incorrectly
supplied by Access.

 

[david epsom dot com dot au]

No, It's not the disappearance of the 'debug' and 'end' buttons
that threw me. It's the fact that it's a completely different
/message/. And the fact that the difference is totally undocumented.

I actually have users that report the error description in some
circumstances, and I use the error description to locate and fix
data-dependent exceptions. How's this grab you: I thought I
could do that.

It may not be clear from the example, but Access has actually
discarded my custom error message, and substituted a different
one.

It's irritating that Access discards the error description and
substitutes a different one. There is a work around, which
only requires that everyone else be very careful when building
new event procedures.

It's irritating that no one bothered to document the difference
between the Access message box and the VB message box, or the
different implementation between MDB and MDE, and the new runtime
behaviour. There is no work around for that, but believe me,
if there WAS a company that was offering an equal product with
an upgrade path instead of planned degradation, I would be out
of here in a moment.

(david)

 

[Albert D. Kallal]

No, It's not the disappearance of the 'debug' and 'end' buttons
that threw me. It's the fact that it's a completely different
/message/. And the fact that the difference is totally undocumented.

I actually have users that report the error description in some
circumstances, and I use the error description to locate and fix
data-dependent exceptions. How's this grab you: I thought I
could do that.

It may not be clear from the example, but Access has actually
discarded my custom error message, and substituted a different
one.

Hum...that is not clear?? Are you saying that if you trap the divide by zero
error, you get a deifernt results?

In other words, if we use:

Private Sub Detail_Click()

Dim i As Integer

On Error GoTo Myer

i = i / 0

Exit Sub

Myer:

Dim im As Integer
Dim strT As String

im = Err.Number
strT = Err.Description

MsgBox "error number = " & im & vbCrLf & _
"Description = " & strT

Resume Next

End Sub

I find that the above reuslts in teh same mesage in a mdb, a mde, and also
when run as a runtime?

And, if you wanted to remove the "Microsoft access" title in the msgbox, and
use "your" application name,
you can use (assuming you set the application title in the startup options).

MsgBox "error number = " & im & vbCrLf & _
"Description = " & strT, , CurrentDb.Properties("AppTitle")
:
Perhaps some value, or some other thing is triggering yet another error
message, and you loosing the current err number/description?

I am using a2003...but I don't think results would be different for
a2000-a2003 versions.

 

[david epsom dot com dot au]

These are the error messages I quoted earlier:

-------
The expression On Click you entered as the event property setting
produced the following error: Overflow.
The expression may not result in the name of a macro, the name of a
user defined function, or [Event Procedure].
There may have been an error evaluating the function event or macro.
-------
Run-time error '6':
Overflow
-------

They are in fact different messages, although both have been constructed
using a text string from the error resource "overflow". Both have included
information that the designer thought was relevant to the target user:

From the VBA designer:
"Run-Time error '6':"

And from the Access designer:
"The expression may not result in the name of a macro...."

-------
For the example message, this might not matter much to your users,
but in the development environment, my message said:

Please discard record and try again.

Overflow
from mcModuleLimit.gfnLimitPercentage.3560
from mcModuleLimit.gfnInsertLimit.2820
from frmMM_Contract_Add.fn_Save.562

....and when Access unexpectedly substituted a different message, it
caused confusion to both the client and the support team.


Now I would argue with the Access designers anyway: They know that
the error was an Overflow error, why confuse things with the general
purpose string referring to general errors in the expression evaluator?
And that additional text DID confuse us: I expect to see that text
when, (normally due to build and reference problems), I have an
expression that does not result in the name of a user defined function.
But that would be assuming that this was a deliberate design decision.
And it would be really getting away from (which I still think is a
relevant issue) that we have a previously undocumented situation where
the error description is discarded, and a different error description
is substituted.

(david)

 

[Albert D. Kallal]

They are in fact different messages, although both have been constructed
using a text string from the error resource "overflow". Both have
included
information that the designer thought was relevant to the target user:

From the VBA designer:
"Run-Time error '6':"

And from the Access designer:
"The expression may not result in the name of a macro...."

You got a fair point here. I am not really trying to throw water on this, or
"butter" over this issue!

However, if you trap the error message, then the messages are the same in
both cases (in fact all 3).

For the example message, this might not matter much to your users,

No, in fact it DOES matter!. For sure, the mde gives different messages
(more user orientated messages, and less developer orientated. And, of
course I pointed out no source code).

but in the development environment, my message said:

I think we both can agree that when you deploy a mde, then messages are
orientated to the "end user"
and NOT the developer. I can even agree to dis-agree that messages should,
or should not be the same.

The main problem here is that ms-access is BOTH a end user product, and ALSO
a developer product. I can't think of other IDE and development system that
is both user, and developer product. Ms-access unique in this regards, and
thus poses many challenges.

So, it does seem that the "differences" in error messages is NOT pointed out
in documentation, and is kind of something everyone over looks.

...and when Access unexpectedly substituted a different message, it
caused confusion to both the client and the support team.

Again, the above is a fair point.

relevant issue) that we have a previously undocumented situation where
the error description is discarded, and a different error description
is substituted.

Again, fair complaint. My only response is that if you install c++ and
visual studio on your pc, then all programs that error out in fact now give
you a "debug" button also! (that even includes ms-access, and office!!). So,
yes, the error messages do change on developers pc's vs others. I not sure
if this is just observation in our industry, or just taken for granted.

You would be hard pressed to find documentation on visual studio that brings
up a debug EVERY where in windows! (and, I bet NONE of the applications, be
it quicken accounting, or Excel explain the sudden appearance of the debug
button either...yet it is there for all to see!).

So, really, at the end of the day, the solution is to put error handling in
all routines that can matter. When you do this, then all error messages will
be the same and consistent at all times, and even the same when your users
run a MDB, MDE, or even a MDE in the runtime..

 

[Marshall Barton]

An excellent discussion. I've learned something
significant, if obscure, from David's well presented
question and Albert's in depth response.

 

[david epsom dot com dot au]

Odd: My reply to this message has gone "deleted from the server"
I've just reviewed the text, and I don't see any bad words,
strange URL's, insulting remarks, name calling, references
to commercial products or companies, or anything else that
would justify deletion. What gives ???


news:[email protected]...

 

[david epsom dot com dot au]

These are the error messages I quoted earlier:

-------
The expression On Click you entered as the event property setting
produced the following error: Overflow.
The expression may not result in the name of a macro, the name of a
user defined function, or [Event Procedure].
There may have been an error evaluating the function event or macro.
-------
Run-time error '6':
Overflow
-------

They are in fact different messages, although both have been constructed
using a text string from the error resource "overflow". Both have included
information that the designer thought was relevant to the target user:

From the VBA designer:
"Run-Time error '6':"

And from the Access designer:
"The expression may not result in the name of a macro...."

-------
For the example message, this might not matter much to your users,
but in the development environment, my message said:

Please discard record and try again.

Overflow
from mcModuleLimit.gfnLimitPercentage.3560
from mcModuleLimit.gfnInsertLimit.2820
from frmMM_Contract_Add.fn_Save.562

....and when Access unexpectedly substituted a different message, it
caused confusion to both the client and the support team.


Now I would argue with the Access designers anyway: They know that
the error was an Overflow error, why confuse things with the general
purpose string referring to general errors in the expression evaluator?
And that additional text DID confuse us: I expect to see that text
when, (normally due to build and reference problems), I have an
expression that does not result in the name of a user defined function.
But that would be assuming that this was a deliberate design decision.
And it would be really getting away from (which I still think is a
relevant issue) that we have a previously undocumented situation where
the error description is discarded, and a different error description
is substituted.

(david)