By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,746 Members | 1,211 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,746 IT Pros & Developers. It's quick & easy.

Error 3021 description problem

P: n/a
I support an MS Access application in which errors are trapped using
the On Error statement. Just recently, the users of this system have
experienced run-time error number 3021 on a random basis. My biggest
problem right now is that the error description associated with this
error is Application-defined or object-defined error. It has always
been my understanding that these error numbers would not be used by
Microsoft and were available to application developers for their use
as in Err.Raise 3021, etc.

When I searched this group for this error, however, I see postings
that would indicate that 3021 is the No current record error. It
would appear that I might be having a problem with the table that
cross-references an error number to its description. I am having this
problem with my version of Access as well as at the client site. Both
sites are running Access 2000 Version 9.

Does anyone know of a fix for this short of reloading MS Access (which
will be a hard sell at the client site). Is this cross-referencing
done with a .dll or some other single file that can be reloaded?
Thanks.
Nov 12 '05 #1
Share this Question
Share on Google+
9 Replies

P: n/a
What do you mean by "these error numbers"? There have always been error
numbers used by the product. My recollection is that the series of errors
reserved for the developers were very large numbers, not the lower ones as
you describe.

Larry Linson
Microsoft Access MVP
"Robert Wing" <rc****@worldnet.att.net> wrote in message
news:9f**************************@posting.google.c om...
I support an MS Access application in which errors are trapped using
the On Error statement. Just recently, the users of this system have
experienced run-time error number 3021 on a random basis. My biggest
problem right now is that the error description associated with this
error is Application-defined or object-defined error. It has always
been my understanding that these error numbers would not be used by
Microsoft and were available to application developers for their use
as in Err.Raise 3021, etc.

When I searched this group for this error, however, I see postings
that would indicate that 3021 is the No current record error. It
would appear that I might be having a problem with the table that
cross-references an error number to its description. I am having this
problem with my version of Access as well as at the client site. Both
sites are running Access 2000 Version 9.

Does anyone know of a fix for this short of reloading MS Access (which
will be a hard sell at the client site). Is this cross-referencing
done with a .dll or some other single file that can be reloaded?
Thanks.

Nov 12 '05 #2

P: n/a
DFS
When is your error occurring? It's most likely not a random event.

You probably have some VBA code trying to reference a recordset which hasn't
returned any records.
"Robert Wing" <rc****@worldnet.att.net> wrote in message
news:9f**************************@posting.google.c om...
I support an MS Access application in which errors are trapped using
the On Error statement. Just recently, the users of this system have
experienced run-time error number 3021 on a random basis. My biggest
problem right now is that the error description associated with this
error is Application-defined or object-defined error. It has always
been my understanding that these error numbers would not be used by
Microsoft and were available to application developers for their use
as in Err.Raise 3021, etc.

When I searched this group for this error, however, I see postings
that would indicate that 3021 is the No current record error. It
would appear that I might be having a problem with the table that
cross-references an error number to its description. I am having this
problem with my version of Access as well as at the client site. Both
sites are running Access 2000 Version 9.

Does anyone know of a fix for this short of reloading MS Access (which
will be a hard sell at the client site). Is this cross-referencing
done with a .dll or some other single file that can be reloaded?
Thanks.

Nov 12 '05 #3

P: n/a
“these error numbers” are the numbers/values that Access
assigns to Err when a runtime error occurs. Err appears to be defined
as a long but I’m not sure that numbers above 65535 are valid.
In pseudo code, this is how you can print all the error codes (i) and
their corressponding description.

for i = 0 to 65535
print #1; i & “ - “ & Error(i)
next I
Nov 12 '05 #4

P: n/a
It is random but probably is occurring during an updating process. If
3021 is No current record then you are right and for some reason the
Recordset is bad or non-existent. Seems like I have tried all the
update combinations, however, and I can’t seem to replicate the
error. I made some code changes and added an error logging table
because of this problem. I didn’t get any entries for several
weeks and thought I had the problem licked. I check the last time I
was onsite and found that the error had occurred a couple of times.
Actually there were six entries total but they occurred in two groups
of three that were logged so close to each other (within seconds) that
I concluded that were part of the same event.

That said, I need to reiterate that my immediate problem appears to be
a problem getting the correct error description that corresponds to
the error number raised by Access. Thanks.
"DFS" <no****@nospam.com> wrote in message news:<vv************@corp.supernews.com>...
When is your error occurring? It's most likely not a random event.

You probably have some VBA code trying to reference a recordset which hasn't
returned any records.

Nov 12 '05 #5

P: n/a
rc****@worldnet.att.net (Robert Wing) wrote in
<9f*************************@posting.google.com> :
That said, I need to reiterate that my immediate problem appears
to be a problem getting the correct error description that
corresponds to the error number raised by Access.


My guess is that the problem is bubbling up through several layers
of unhandled errors. That is, you're getting the error message in a
context that is *very* different from the context that is actually
generating the error itself, and that's why it doesn't make any
sense.

This is a case where you need to have one of two situations:

1. everything error trapped.

OR

2. nothing error trapped.

With 1), you'll get the error in the immediate context in which it
occurs. With 2), you'll get the Access debugger's response to the
original error. Either way, you'll then know what is *really*
causing the error.

For what it's worth, I've found A2K to be much worse about
preserving original error context than A97. That is, practices that
worked fine for me for years and years are now causing problems
when the code is converted to A2K.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #6

P: n/a
Larry - I just realized that the answer that I posted to you question
earlier is off the mark. My reference to "these error numbers" refers
to all error numbers that cross-reference to the description
"Application-defined or object-defined error". Sorry.

"Larry Linson" <bo*****@localhost.not> wrote in message news:<bC*******************@nwrddc02.gnilink.net>. ..
What do you mean by "these error numbers"? There have always been error
numbers used by the product. My recollection is that the series of errors
reserved for the developers were very large numbers, not the lower ones as
you describe.

Larry Linson
Microsoft Access MVP

Nov 12 '05 #7

P: n/a
I'm new to this forum and need some basic help: how do you get
special characters to display correctly versus the &#8220, etc. that I
am getting (see below)? Thanks.

rc****@worldnet.att.net (Robert Wing) wrote in message news:<9f**************************@posting.google. com>...
“these error numbers” are the numbers/values that Access
assigns to Err when a runtime error occurs. Err appears to be defined
as a long but I’m not sure that numbers above 65535 are valid.
In pseudo code, this is how you can print all the error codes (i) and
their corressponding description.

for i = 0 to 65535
print #1; i & “ - “ & Error(i)
next I

Nov 12 '05 #8

P: n/a
I think I have everything trapped but you have a good point. I'm not
sure I totally understand the "several layers of unhandled errors" you
mentioned but it seems that once you execute an On Error clause it
stays in effect even if you subsequently call another function or
subroutine unless you execute another On Error clause in the called
routine. Actually, now I wonder if part of my problem is the On Error
clause that executes in the called routine. I need to test that. I
try to display where the error occurs but that may not be working
correctly. I turn off error trapping when I am debugging in test but
I don't like to turn off all error trapping in production because the
users can be thrown into the code.

But I have a more fundimental problem here as well: If I go into the
immediate debug window and type: ? Error(3021) the response is
"Application-defined or object-defined error"
Based on what I see on this forum, if I enter: ? Error(3021) the
response should be: "No current record....", i.e, I think the process
that cross-references the error number to its corresponding error
description is malfunctioning and I don't know how to fix it.

dX********@bway.net.invalid (David W. Fenton) wrote in message news:<94***************************@24.168.128.74> ...
rc****@worldnet.att.net (Robert Wing) wrote in
<9f*************************@posting.google.com> :
That said, I need to reiterate that my immediate problem appears
to be a problem getting the correct error description that
corresponds to the error number raised by Access.


My guess is that the problem is bubbling up through several layers
of unhandled errors. That is, you're getting the error message in a
context that is *very* different from the context that is actually
generating the error itself, and that's why it doesn't make any
sense.

This is a case where you need to have one of two situations:

1. everything error trapped.

OR

2. nothing error trapped.

With 1), you'll get the error in the immediate context in which it
occurs. With 2), you'll get the Access debugger's response to the
original error. Either way, you'll then know what is *really*
causing the error.

For what it's worth, I've found A2K to be much worse about
preserving original error context than A97. That is, practices that
worked fine for me for years and years are now causing problems
when the code is converted to A2K.

Nov 12 '05 #9

P: n/a
rc****@worldnet.att.net (Robert Wing) wrote in
<9f**************************@posting.google.com >:
I think I have everything trapped but you have a good point. I'm
not sure I totally understand the "several layers of unhandled
errors" you mentioned but it seems that once you execute an On
Error clause it stays in effect even if you subsequently call
another function or subroutine unless you execute another On Error
clause in the called routine. Actually, now I wonder if part of
my problem is the On Error clause that executes in the called
routine. I need to test that. I try to display where the error
occurs but that may not be working correctly. I turn off error
trapping when I am debugging in test but I don't like to turn off
all error trapping in production because the users can be thrown
into the code.
Well, if you're not trapping errors in subroutines called in the
context in which your error handler is reporting the error, then
your choice is to turn off that local error handler or to add error
handling to all the subroutines called by it. One of these will
surely eventually flush out which exact line of code is truly
causing the error.
But I have a more fundimental problem here as well: If I go into
the immediate debug window and type: ? Error(3021) the response is
"Application-defined or object-defined error"
Based on what I see on this forum, if I enter: ? Error(3021) the
response should be: "No current record....", i.e, I think the
process that cross-references the error number to its
corresponding error description is malfunctioning and I don't know
how to fix it.


But, as I said, the whole point is that in the context where the
error is being reported, you may not be in Jet/DAO, so you don't
get the appropriate error description. If the error handler is in a
context where it can't get to Jet/DAO (which is who the NO CURRENT
RECORD error belongs to, so far as I can tell), then the
"application" that is running (which is something *other* than
Jet/DAO) doesn't define the error message, and you're getting an
absolutely correct result, however useless it may be. Indeed, now
that I've thought about it, it indicates to me pretty clearly that
the error must be occurring in something at a lower level than the
error handler is defined.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.