Get actual text of error trapped by Form_Error?

[TC]

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped by
the Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template text
like: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so on.
I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[DFS]

TC,

In the Form_Error event, add this line:

MsgBox AccessError(DataErr)

and you'll be able to see the actual text - at least I could for run-time
errors 3022 (dupes) and 2169 (can't save record).


"TC" <a@b.c.d> wrote in message news:1071375900.155857@teuthos...

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped by
the Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template text like: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so on. I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[Steve Jorgensen]

There is a way to do this, but it's really bizzare, and the technique cannot
be made to work flawlessly in Access 2000, only in 97 or 2002.

Basically, you have to intercept every attempt to save or delete a record
using BeforeUpdate or BeforeDeleteConfirm, perrform the action yourself on the
form's RecordsetClone, then cancel the event. Since the actual update happens
in VB code, you can capture the error there.

In order to perform the update in code, you have to loop through all the form
controls, and determine which ones have ControlSource properties, and have
them set to non-blank text that does not begin with the = Character, and copy
the data from the control values into the recordset field values.
Additionally, you have to make sure you don't copy any value that IsEmpty,
since those fields should receive their default values, and you must also make
sure the field in the recordset is updateable, not read-only.

Note that no techniques for determining the updateability of are 100% reliable
with ODBC linked tables, so you may have to use a tag property or something to
indicate non-updateable fields that are not properly reflected in the field
object properties.

Note that a partial solution can be found on MS Support in article 185384.
The don't say it's partial, but I found that you have to add a lot of special
case checks for any real-worls usage, and it doesn't cover the case of
deleting a record.

On Sun, 14 Dec 2003 14:55:24 +1200, "TC" <a@b.c.d> wrote:

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped by
the Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template text
like: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so on.
I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[Steve Jorgensen]

That does work for error messages that do not have replaceable, case-specific
arguments, but does not work for error messages with replaceable arguments.
It also doesn't work for ODBC errors, so any ODBC error will simply say "ODBC
Error" - not very useful.

On Sat, 13 Dec 2003 23:49:20 -0500, "DFS" <no****@nospam.com> wrote:

TC,

In the Form_Error event, add this line:

MsgBox AccessError(DataErr)

and you'll be able to see the actual text - at least I could for run-time
errors 3022 (dupes) and 2169 (can't save record).


"TC" <a@b.c.d> wrote in message news:1071375900.155857@teuthos...

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped by
the Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template

text

like: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so

on.

I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[David W. Fenton]

no****@nospam.nospam (Steve Jorgensen) wrote in
<a3********************************@4ax.com>:

Basically, you have to intercept every attempt to save or delete a
record using BeforeUpdate or BeforeDeleteConfirm, perrform the
action yourself on the form's RecordsetClone, then cancel the
event. Since the actual update happens in VB code, you can
capture the error there.

Sounds like an unbound form would solve the problem, no?

But, of course, you'd have to code replacements for all the events
that unbound forms don't have.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Sun, 14 Dec 2003 20:54:23 GMT, dX********@bway.net.invalid (David W.
Fenton) wrote:

no****@nospam.nospam (Steve Jorgensen) wrote in
<a3********************************@4ax.com>:

Basically, you have to intercept every attempt to save or delete a
record using BeforeUpdate or BeforeDeleteConfirm, perrform the
action yourself on the form's RecordsetClone, then cancel the
event. Since the actual update happens in VB code, you can
capture the error there.

Sounds like an unbound form would solve the problem, no?

But, of course, you'd have to code replacements for all the events
that unbound forms don't have.

The main problem with unbund forms is that they cannot be continuous, and I
find continuous forms too compelling to omit. Even if the main form could be
non-continuous, I almost always want some kind of editable, continuous
subform.

[TC]

Thanks for that, but it's the errors with "replaceable arguments" that I'm
on about. With those errors, the AccessError() messages contain placeholders
like |1, |2 etc. The actual messages (displayed at runtime) have explicit
names (of tables or whatever) in those positions. I need those explicit
names.

Thanks,
TC
"DFS" <no****@nospam.com> wrote in message
news:vt************@corp.supernews.com...

TC,

In the Form_Error event, add this line:

MsgBox AccessError(DataErr)

and you'll be able to see the actual text - at least I could for run-time
errors 3022 (dupes) and 2169 (can't save record).


"TC" <a@b.c.d> wrote in message news:1071375900.155857@teuthos...

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped by the Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template

text

like: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so

on.

I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[TC]

Ok, thanks. That's a neat idea, that I will remember! But it would be
overkill for my current need.

I have a generic Form_Error handler that I can call from any form in any
application. It already handles various errors, such as, the 3 or 4
variations of "missing required field". For those errors, for example, it
just iterates the form controls, in tab order, looking for the first one
which is null (or ""), but bound to a mandatory field. Then it moves the
cursor to that control, & says "This value must be entered".

I wanted to enhance this handler with some extra errors. However, none of
the errors in question can be handled accurately, unless you know the actual
table(/whatever) names, from the runtime error message. That's why I need
the actual message. But it seems that it can not be done directly, from
within Form_Error :-(

Thanks for the suggestion,
TC
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:a3********************************@4ax.com...

There is a way to do this, but it's really bizzare, and the technique cannot be made to work flawlessly in Access 2000, only in 97 or 2002.

Basically, you have to intercept every attempt to save or delete a record
using BeforeUpdate or BeforeDeleteConfirm, perrform the action yourself on the form's RecordsetClone, then cancel the event. Since the actual update happens in VB code, you can capture the error there.

In order to perform the update in code, you have to loop through all the form controls, and determine which ones have ControlSource properties, and have
them set to non-blank text that does not begin with the = Character, and copy the data from the control values into the recordset field values.
Additionally, you have to make sure you don't copy any value that IsEmpty,
since those fields should receive their default values, and you must also make sure the field in the recordset is updateable, not read-only.

Note that no techniques for determining the updateability of are 100% reliable with ODBC linked tables, so you may have to use a tag property or something to indicate non-updateable fields that are not properly reflected in the field object properties.

Note that a partial solution can be found on MS Support in article 185384.
The don't say it's partial, but I found that you have to add a lot of special case checks for any real-worls usage, and it doesn't cover the case of
deleting a record.

On Sun, 14 Dec 2003 14:55:24 +1200, "TC" <a@b.c.d> wrote:

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped bythe Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template textlike: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so on.I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[Tom van Stiphout]

On Sun, 14 Dec 2003 14:55:24 +1200, "TC" <a@b.c.d> wrote:

After seeing Steve's "solution", I would rather use the method I'm
typically using: forego the Form_Error handler altogether, and have
error handling in every procedure. This error handling is added by an
add-in we wrote, and calls a central error handling function (where we
typically suppress error 2501, etc).

-Tom.

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped by
the Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template text
like: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so on.
I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[Michael \(michka\) Kaplan [MS]]

There are some errors that will not be caught using your method, and
Form_Error is needed for them.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Tom van Stiphout" <to*****@no.spam.cox.net> wrote in message
news:87********************************@4ax.com...

On Sun, 14 Dec 2003 14:55:24 +1200, "TC" <a@b.c.d> wrote:

After seeing Steve's "solution", I would rather use the method I'm
typically using: forego the Form_Error handler altogether, and have
error handling in every procedure. This error handling is added by an
add-in we wrote, and calls a central error handling function (where we
typically suppress error 2501, etc).

-Tom.

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped bythe Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template textlike: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so on.I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[TC]

I don't see how that helps. If you are not using Form_Error - and you are
not using a solution like Steve's - then you will get the default Access
error messages for the errors that would otherwise fire Form_Error. (I don't
see how error handlers anywhere, would trap those errors, in the absemce of
a solution like Steve's.) The point of my exercise is to replace those
standard errors - many of which are very confusing to the end-user.

Cheers,
TC
"Tom van Stiphout" <to*****@no.spam.cox.net> wrote in message
news:87********************************@4ax.com...

On Sun, 14 Dec 2003 14:55:24 +1200, "TC" <a@b.c.d> wrote:

After seeing Steve's "solution", I would rather use the method I'm
typically using: forego the Form_Error handler altogether, and have
error handling in every procedure. This error handling is added by an
add-in we wrote, and calls a central error handling function (where we
typically suppress error 2501, etc).

-Tom.

Folks

Is there >>ANY<< way to get the actual text of an error that is trapped bythe Form_Error event?

I mean actual text like: "duplicate record in table XYZ", not template textlike: "duplicate record in table |1".

I need this for a general purpose error handler. I've tried everything
obvious, including err.description, the dbengine.errors collection & so on.I think the answer is NO. I would like to be proved wrong.

TIA,
TC

[Tom van Stiphout]

On Mon, 15 Dec 2003 10:57:45 +1200, "TC" <a@b.c.d> wrote:

Sorry, I was too quick to pull the trigger. You are correct; bound
forms can generate certain events only Form_Error can trap. It would
be nice if MSFT would expose more information to us developers. You
would think after 8 versions they might have gotten around to it...

-Tom.

I don't see how that helps. If you are not using Form_Error - and you are
not using a solution like Steve's - then you will get the default Access
error messages for the errors that would otherwise fire Form_Error. (I don't
see how error handlers anywhere, would trap those errors, in the absemce of
a solution like Steve's.) The point of my exercise is to replace those
standard errors - many of which are very confusing to the end-user.

Cheers,
TC
"Tom van Stiphout" <to*****@no.spam.cox.net> wrote in message
news:87********************************@4ax.com.. .

On Sun, 14 Dec 2003 14:55:24 +1200, "TC" <a@b.c.d> wrote:

After seeing Steve's "solution", I would rather use the method I'm
typically using: forego the Form_Error handler altogether, and have
error handling in every procedure. This error handling is added by an
add-in we wrote, and calls a central error handling function (where we
typically suppress error 2501, etc).

-Tom.

>Folks
>
>Is there >>ANY<< way to get the actual text of an error that is trappedby >the Form_Error event?
>
>I mean actual text like: "duplicate record in table XYZ", not templatetext >like: "duplicate record in table |1".
>
>I need this for a general purpose error handler. I've tried everything
>obvious, including err.description, the dbengine.errors collection & soon. >I think the answer is NO. I would like to be proved wrong.
>
>TIA,
>TC
>
>
>

[TC]

"Tom van Stiphout" <to*****@no.spam.cox.net> wrote in message
news:73********************************@4ax.com...

On Mon, 15 Dec 2003 10:57:45 +1200, "TC" <a@b.c.d> wrote:

Sorry, I was too quick to pull the trigger. You are correct; bound
forms can generate certain events only Form_Error can trap. It would
be nice if MSFT would expose more information to us developers. You
would think after 8 versions they might have gotten around to it...

(snip)

The flip side to that, is this: how come developers have accepted the crummy
default messages for so long? One of the most common user errors (missing
required field) comes in several versions that will surely confuse the user.
Don't we all have users saying, "WTF does >that< message mean?"

TC
(off for the day)

[Tom van Stiphout]

On Mon, 15 Dec 2003 11:29:57 +1200, "TC" <a@b.c.d> wrote:

I agree. Perhaps we are too complacent.

One idea is to start a "I wish MSFT would get around to fixing this
problem" list. If it is in a well-traveled location (our official CDMA
site comes to mind - but I wouldn't presume to claim space on it), and
if it were quick to respond to new (beta) versions, perhaps MSFT would
take notice. Perhaps journalists writing glowing articles about the
next version of Access would take notice.
Contributions would be sent into a central location, perhaps this
newsgroup, and only be added to the list upon recommendation of
several people (to avoid "Function Left$ not found" entries).

I floated a trial balloon along these lines a year or more ago
(related to performance testing). No takers at that time. I'm floating
another one now.

-Tom.

"Tom van Stiphout" <to*****@no.spam.cox.net> wrote in message
news:73********************************@4ax.com.. .

On Mon, 15 Dec 2003 10:57:45 +1200, "TC" <a@b.c.d> wrote:

Sorry, I was too quick to pull the trigger. You are correct; bound
forms can generate certain events only Form_Error can trap. It would
be nice if MSFT would expose more information to us developers. You
would think after 8 versions they might have gotten around to it...

(snip)

The flip side to that, is this: how come developers have accepted the crummy
default messages for so long? One of the most common user errors (missing
required field) comes in several versions that will surely confuse the user.
Don't we all have users saying, "WTF does >that< message mean?"

TC
(off for the day)