Microsoft Access Dreaded 2486 Bug - "You can't carry out this action at the present time"

[Ernie Page]

I am experiencing the dreaded Microsoft Access 2486 bug which gives the
message

"You can't carry out this action at the present time"

I have read many postings to this news group on this problem with many
different suggestions.

None seem to work.

I have decompiled, and recompiled.

I have inserted DeEvents here and there.

Any suggestions.

Thanks,

Ernie Page

[Allen Browne]

Ernie, there are many reasons why you may get this error. Mostly, it's a
matter of understanding how Access works, so you don't ask it to do
something inappropriate.

Some examples:
- You tried to move to a new record, when you are already at a new record.

- You tried to undo a record that is not dirty.

- You tried to perform a DoMenuItem operation from a popup window.

- You tried to do something that can't be done in that event. (For example,
you can't move to a different record in the form's Current event, coz it's
still moving to this record.)

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to the newsgroup. (Email address has spurious "_SpamTrap")

"Ernie Page" <ebp...@ebpage.com> wrote in message
news:bdmsp2$rt6$1...@terabinaries.xmission.com...

[Tom van Stiphout]

On Sun, 29 Jun 2003 08:23:17 -0600, "Ernie Page" <ebp...@ebpage.com>
wrote:

The allowed actions typically follow pretty closely the menu options
that are available at any given point.
One example (also mentioned by Allen): Open the Northwind sample
application. Open the Employees form. Select menu option Insert New
Record. Try to insert another record by selecting that menu option
again. You'll find it is disabled, because it wouldn't make sense.

-Tom.

[David W. Fenton]

abrowne1...@bigpond.net.au (Allen Browne) wrote in
<cSMLa.173$VH3....@news-server.bigpond.net.au>:

>Ernie, there are many reasons why you may get this error. Mostly,
>it's a matter of understanding how Access works, so you don't ask
>it to do something inappropriate.

There are also plenty of cases where runtime error 2486 comes up
that are because of bugs in Access.

Specifically, in this circumstance:

When you refer in code in a subform to a field in the recordset of
the parent form of the subform.

Now, it won't *immediately* cause an error, but it will eventually.

And the culprit is a dependency on Msvcrt.dll.

Of course, I'm speaking of Access 2000.

And I have never been able to 100% reliably produce the error! It
seems most common if the app is running on NT 4, but still happens
in Win2K (dunno about WinXP).

Now, the particular version of runtime error 2486 that I describe
above *does not occur in Access97* -- it's a change in the way
Access2K resolves references to fields and controls in code. To put
it another way, the code that often causes this error in A2K
*never* produces the error in Access97.

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

[ernie]

Allan, Tom, David:

Thanks for responding.

I don't think that I am doing something obviously inappropriate.
Virtually the same code has been working for months.

I have two forms that are virtually identical (one has a few additional
controls). Each form has a timer event.
Each form has a button that opens a report which generates a printer
friendly version of the form.

Form A works fine now. I can open the form, open the report, close the
report, and everything is peachy!

On form B, I can open the report. I can click on the button which opens
the printer friendly report. I then close the report. Everything
appears fine. But the next time I try to open the report, or close the
form, I get the dreaded 2486 error. Of course, I am screwed at that
point.

Form A used to exhibit the same problem, but I copied all objects to a
blank mdb file, and Form A stopped exhibiting the problem.

It appears to me that there is something subtle (and fishy) going on.

I have looked at the many, many news items posted on the news groups
relating to the 2486 bug. Many of the solutions amount to voodoo
(repairing corrupted databases, deleting temp files, etc).

Lots of folks report that the problem does not occur in Access 97.

Any help would be appreciated.

Ernie

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[ernie]

David:

Thanks for your reply.

I do not have a sub-form in my form, so that is not the culprit.

[Allen Browne]

First step for debugging might be to remove the form's Timer event. Lots of
things could be inappropriate in that event, not to mention the interaction
of events.

Which event throws the error? If it's the Click event of the command button,
post the code for that button.

Checking if the form is dirty before making changes is always worthwhile.

Look for other areas that could cause interacting events. For example, if
the button has a hotkey (ampersand in its caption/label), the focus may be
in another control, which needs to get processed before the hotkey can
actually call the Click event of the command button.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to the newsgroup. (Email address has spurious "_SpamTrap")

"ernie" <news_...@summit-systems-timers.com> wrote in message
news:3f007a22$0$205$7586...@news.frii.net...

[David W. Fenton]

news_...@summit-systems-timers.com (ernie) wrote in
<3f00812b$0$197$7586...@news.frii.net>:

>I do not have a sub-form in my form, so that is not the culprit.

You say that you're opening a report. Are you passing criteria to
the report? If so, does that criterion use the value in a control
or the value from a field in the underlying recordset? Or a value
from a control that has the same name as the underlying recordset?

I would do these things to eliminate this as a possible cause of
the problem:

1. rename the control to have a name that is different from the
controlsource (this is good practice for any control that is
referred to in code as it explicitly disambiguates what otherwise
must be disambiguated by VBA, which might very well guess wrong).

2. use the control for passing the criteria to the report.

If you don't have a control on the report that displays the value
from the underlying recordset that you need to pass to the report
(this is quite common, since users don't need to see your ID
fields), then create a control, give it a name different from the
underlying filed and set its .Visible property to FALSE. Then use
that control for passing the criteria.

It's a long shot, but it would be consistent with the version of
this error I lost so much hair over!

[cmbi...@bigpond.com]

Hi everyone,

I think I may have an answer. Its related old problem that plagued me mercilessly.
If I ever DELETED a form, and then copied a new form in with the SAME NAME
Access simply goes crazy. I have just encountered your error, and I had just replaced a non working version of a form with a new version with the SAME NAME and it went crazy. SO I tried renaming the form to formname_new, then renamed all my references and VOIILA ! the world is sane again.
Hope this helps.
Blessings,
Colin