mso9.dll/msaccess error

[Mark A. Weber]

Hello everyone! I posted this message in a few other groups and it was
recommended to me by a reader that this might be the best group in which to
post it. We have recently re-vamped an Access application such that in each
of our 5 locations a local SQL server receives published updates from our
main office server. Remote servers also send their local updates to the
master and they are in turn propogated to all of the other remote servers.
The new design works great except for one annoying bug we have been chasing
for two weeks: "Faulting application msaccess.exe, version 9.0.0.2719,
faulting module mso9.dll, version 9.0.0.2720, fault address 0x0007ee2d."
When a user gets the error, they hit close and it terminates Access. If they
move the error off the screen and continue working the application continues
but slows to a crawl. The users have discovered this and have been doing so
but the fact that the error appears must be fixed. The error occurs randomly
and users are all using different forms and performing different tasks in
the application. For the most part, it frequently happens when users have
the app minimized or leave it on the screen for a few minutes but it also
happens while they are actively using the system. If anyone can point me in
the right direction it would be greaatly appreciated. Thanks in advance!

- Mark
mweber_at_warrenlumber_dot_com

 

['69 Camaro]

Hi, Mark.

Have the latest versions of service packs, Office 2K SP-3 and Jet 4.0 SP-8,
been installed on all of these computers?

Remote servers also send their local updates to the
master and they are in turn propogated to all of the other remote servers.

Your wording sounds like Replication may be in use. The database isn't
using Access Replication, is it?

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Mark A. Weber]

I thank you very much for the advice. We were not on the SP levels you
recommended so we downloaded/applied them and the problem remains. The
database is using SQL replication. At this point we are looking at the code
perhaps a new control we are using that was not in the previous version.

Once again, we reaally appreciate the effort!

- Mark

 

['69 Camaro]

Hi, Mark.

and the problem remains.

From the error message, you may have a corrupted mso9.dll file, or the file
might just need to be reregistered with the Windows operating system. You
can try reregistering it by using syntax such as the following in the
Windows Start -> Run dialog text box:

regsvr32 "C:\Program Files\Microsoft Office\Office\MSO9.DLL"

Of course, this depends upon the directory path of your computer's Microsoft
Office installation. Yours may differ.

The
database is using SQL replication.

That's good news.

At this point we are looking at the code
perhaps a new control we are using that was not in the previous version.

Using ActiveX controls from Access can be problematic, i.e., they may fail
to work on certain computers, simply because the computers aren't configured
_exactly_ the same as the development computer (often due to a different
version of the ActiveX control or can even be due to the placement of the
file in a different directory).

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Mark A. Weber]

We tried reinstalling and reregistering mso9.dll. N/G. The programmer
assures me that the file locations are standard because the re-write was
developed on the same imaged system that wasa deployed to the users-to avoid
that sort of problem.

Life sure gets tedious, don't it!

- Mark

 

['69 Camaro]

Hi, Mark.

the re-write was
developed on the same imaged system that wasa deployed to the users-to avoid
that sort of problem.

I can think of two things that would cause this:

1.) Something doesn't match the development computer, or else the user's
computers wouldn't have the problem. That "something" is critical.

2.) Perhaps the difference isn't the computer configuration, but the "load"
on the database application. The developer didn't have multiple users in
the database at the same time that he was testing, so there may not have
been enough of a load to experience the problem that is occurring with the
production version. It might very well be that _all_ of the computers'
system images have the same problem, but it wasn't discovered till the
application went "live" in the production version with a full load of users,
network usage and database usage.

An expert needs to investigate this to determine the problem.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Mark A. Weber]

Thanks again for your help!

Take care.

- Mark

Hi, Mark.


I can think of two things that would cause this:

1.) Something doesn't match the development computer, or else the user's
computers wouldn't have the problem. That "something" is critical.

2.) Perhaps the difference isn't the computer configuration, but the "load"
on the database application. The developer didn't have multiple users in
the database at the same time that he was testing, so there may not have
been enough of a load to experience the problem that is occurring with the
production version. It might very well be that _all_ of the computers'
system images have the same problem, but it wasn't discovered till the
application went "live" in the production version with a full load of users,
network usage and database usage.

An expert needs to investigate this to determine the problem.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)


but

 

['69 Camaro]

You're welcome! Good luck.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)