Error 2950 - Reserved Error on form refresh/requery

[Stuart Carstairs]

Hi,

Beating my head against the wall a little on this.

Have an intermittent error 2950 occuring in an access 2000 format database
running in Office XP/2003.

It appears to occur on a form refresh/requery or listbox setfocus but not
all the time, all i have to go on is the 2950 and cannot find help on that.

On drilling into the error on the one and only occasion I have seen the
error it said no current record or out of range on the lstbox.

This is where is gets weird, it happens on most pc's, very intermittent, no
apparent trigger to replicate on demand. 2 of the users (one running office
2003, one office xp) freeze the access database where the rest can just
click end and continue working.

Any ideas on where to go with this one.

 

[Allen Browne]

Stuart, I don't have any specific info on this error, so if someone else
does, I hope they chip in too.

Since the behavior is inconsistent and different on different machines, the
first thing to look for would be differences between the machines.
Particularly, are there differences between the versions of msaccess.exe or
msjet40.dll? More info about the versions expected:
http://allenbrowne.com/ser-53.html#MSAccess

If that is not the issue, another possibility is the chain of events that
happen to be in the queue at the time the problem occurs. One event can
trigger others, and so the problem may occur only when a specific chain is
fired. You can avoid many of these weird errors by explicitly saving the
record first. Try:
If Me.Dirty Then Me.Dirty = False
before anything that would require the record to be saved, such as a
requery, find, sort, filter, close, ...

As an example of the event chain you could trigger, if you have code in the
KeyDown event of a bound control that attempts to move record, you may have
fired:
- the control's KeyPress,
- the control's KeyUp,
- the control's Change,
- the control's BeforeUpdate,
- the control's AfterUpdate,
- the control's LostFocus,
- the control's Exit,
- the next control's GotFocus
- the next control's Enter
- the form's KeyPress,
- the form's KeyUp,
- the form's BeforeUpdate,
- the form's AfterUpdate,
- the form's AfterInsert,
- the form's Current event,
- the Current event of any subforms on the form,
- the Enter and GotFocus events of the active control on each subform,
and each of those events could contain code that triggers other events.

 

[Stuart Carstairs]

Hi Allen,

Thanks for your response, tried a few things since your post....

The problem has gradually gotten worse and occurs almost everytime now.

The triggering event is a listbox after update that does 2 things only:

Requery

Setfocus to the listbox

I put error handling in place to catch the specific error, it just froze
access so I modified error handling to call requery again, this allows the
database to continue running but has a sideeffect which I have no idea
about...

Now the users cannot double click on the listbox, which calls a button click
event which opens a form, without the error handling catching the error and
refreshing the form but if you click the button it opens the form fine. The
only line of code in the double click event is:

buttEditJob_Click

Adding the Call keyword does not make any difference.

I have checked Jet versions and the server and workstations are all running
current version for windows XP.

Not sure if the dirty record state applies as there is no data updating or
editing occuring on the main form but it can occur (depending on user
action) on the sub-form, how best should the dirty record handling be done?
Will calling on the main form propogate to the sub-forms?

I tried to extract more info from the error but nothing useful comes from
the err object.

Any more ideas?

The users each have their own copy of the front-end of the database
(back-end with data only on server) which is identical. The server does not
appear to have this issue at all and it has office XP with msjet40.dll
version 4.0.9025.0 and the workstations have a mix of office XP and 2003
with msjet40.dll version 4.0.8618.0

Any further help will be much appreciated.

 

[Allen Browne]

Okay, I don't see anything here that should be giving the problem.

When you talk about a Requery, I'm not clear if you are requerying the form
or the list box. Presumably you are explicitly requerying the list box,
e.g.:
Me.List1.Requery

The possibility of endlessly triggering events still exists. I got caught
with that again last week. (A combo with conditional formatting that was
constantly being redrawn if the form opened with the mouse over it, even
with no code in any events.)

If you want to pursue it, it's best to put your effotst into identifying the
cause of the problem rather than trying to find workarounds IMHO.

 

[Stuart Carstairs]

Hi Allen,

The workaround in place is to try and keep the client operating, I am trying
to find the cause but good old cryptic microsoft errors don't help too much,
and I can't leave the client with an unusable database while I try to
decipher an error message where the only usable information is "Error 2950:
Reserved Error"

The requery is on the form (so the data displayed in the sub-forms refreshes
to match selected data in listbox)

If the dirty data is a possibility how does that work for a form with
sub-forms? Do i just call dirty=false on the main forms or does it need to
be called for each subform aswell in the form.current event?

Any further help would be appreciated
Stuart

 

[Allen Browne]

Each form has its own Dirty property, so you need to handle each subform.

If you show the Record Selector, its icon changes into a pencil when the
form is dirty. This might help you identify which one is dirty, so you can
then trace why. Typically it's because something is assigning a value to a
bound control. The worst cases are if this happens in the Current event of
the form (so it dirties as soon as you move to a record), or in the
AfterUpdate event of the form (so it dirties as soon as it saves.)