Sharing other Access libraries on the server  could be the cause.

Tony

Rubbish.   Access is a fine tool.  I know of one person who has over
ten thousand people using an Access app against a SQL Server backend.

Those folks who are laughing think you have to throw lots of fancy,
expensive tools and consultants to get a so called enterprise solution
working.   Which is completely wrong.   Although to be fair this is
what many folks within Microsoft are also saying.

Sure there are situations where the latest  Net solution is
appropriate.   There is one person who states that his company
multiplies .Net quotes by a factor of six over the same app in Access.

Tony

No, I do not, after reading your rant, agree that it was stupid to implement
your ERP system with an Access client. You have swallowed a lot of
propaganda, I fear. But this is not the venue to spread that kind of
propaganda with no fear of response.

I have used Access (and Microsoft VB) as a development tool since 1993,
after a long career in mainframes and minicomputers. Most of the paying work
I've done with Access has been with Access as a client, in versions from 2.0
to the current 2003, to various ODBC-compliant server databases from
Microsoft, Sybase, and Informix. I've also used Access 2000 with an ADP
client to Microsoft SQL Server. None, not one, of those applications
experienced the kind of errors you describe with the frequency you describe.

As each user should have their own copy of the front end and all libraries,
and will be individually connected to the server, there is no user audience
limitation, except the number of connections supported by the server. I have
personally worked on Access-client-to-server applications with user
audiences in the low hundreds and have observed successful implementations
with even larger user audiences. How many concurrent users do you have?

For your information, Microsoft VB applications have to connect to the
server in exactly the same manner as Access clients, using either ODBC to
connect to the tables and DAO code, or ADO and ADODB -- thus have no
inherent advantage. In fact, since they rely more on user-written code,
which will certainly not have been as well-tested as the built-in
functionality of Access, they are likely to be less reliable.

If you have a web-based application, or a distributed enterprise-level
application, then it is possible that you might gain by using the new
ASP.NET capabilities. ADO.NET, built on a different base and object model
from the "classic ADO" available in Access, is said to be pretty good.

But, for the client-server application you describe, there's nothing at all
wrong with Access as a client, and a reliable ODBC-compliant server. In
fact, there is strong sentiment among many of those who really know database
work (rather than seizing on rumors to try to explain their own problems)
that Access is the best client for client-server database applications. For
client-server work, moving to DotNet is certainly likely to increase your
requirements for hardware capacilty and memory.

If your environment does not provide for regular updating of installed
software, then you have far greater issues than "Access client software".
If your Access 2000 does not have all the Service Packs applied, then you
are just asking for trouble. Why do you bother with all those tests and
trials if you are not even able to keep your software up-to-date? No matter
how much you test things that are working, that is not going to move the
problems from where they exist to those areas.

I am sure you are aware that Access 2000 is now "out of service" with
Microsoft. If I were going to use an "out of service" product, I'd far
prefer Access 97 with both Service Releases and the few minor patches that
followed SR2.

BTW, Tony is correct that those users sharing the libraries on the server is
one potential cause -- that's no different than having multiple users logged
in to the same client or monlithic database.

Write again when you have provided each user with his/her own copy of the
now-shared libraries and when you are up-to-date with Service Releases and
Service Packs, and perhaps you'll be at a point where someone can offer
other useful suggestions.  With the rapidity of developments in the computer
world, what you are asking is something like, "My 1946 Cadillac has never
been maintained, smokes a lot, and won't go very fast -- what can I do to
make it better?" And then reporting that "No, I can't get regular oil
changes, I can't get the engine rebuilt, and I can't get the other broken
parts replaced, so it must be that 1946 Cadillacs were just bad cars and it
was stupid of the company to buy one back in 1946."

In neither case does "blaming the tool" give you the remotest chance of
correcting the problem.

 Larry Linson
 Microsoft Access MVP