Disk or Network Error in Access 2003

  • Thread starter Thread starter Amy E. Baggott
  • Start date Start date
A

Amy E. Baggott

I have an Access Database that has run stably for a few years, but has
suddenly started throwing "Disk or Network Errors" on both the front and back
end or just freezing with no explanation. The user then has to click OK a
few dozen times before it will let you close (or just use End Task), but when
you open it back up almost immediately, it's fine. This happens at random
and just started this week. My IT Network Admin says it's not a network
problem, and I'm inclined to agree because it isn't affecting anything else
that runs on the network.

Any ideas? It's getting to be a serious pain in the arse. TNX
 
Databases are heavy users of networks and are sensitive to any network
problems. Most other applications will try again to get the data if they run
into a problem. So if word tries to fetch a document and something goes
wrong, it will probably try to fetch the document again, and you will never
see a message that something went wrong the first time it tried.

If this problem is affecting many users then I would suspect that there is a
network problem of some type.

Other possibilities would be patches to the Access software that just got
applied and has now triggering something to cause this.

John Spencer
Access MVP 2002-2005, 2007-2009
The Hilltop Institute
University of Maryland Baltimore County
 
The problem may not be necessarily that there's a lack of network but
rather merely a network disruption. If my memory serves, simply
unplugging ethernet while the Access application is open is enough to
cause that unsavory error. I know that your Network Admin says it's not
a network problem, but if there's a funky network card on the network
that causes more disconnection/disruptions, it's enough to trigger the
errors. This is even true even if the computer with the funky network
card can surf the website and use other network resources without any
apparent disruptions.

As far as I know, the error is basically untrappable, so prevention is
the only thing you can do.
 
Banana said:
The problem may not be necessarily that there's a lack of network
but rather merely a network disruption.
Click to expand...

And the disruption can be for a very tiny interval.

What it means is that when Access/Jet/ACE last tried to ping the
locking file for the data file across the network, the ping failed.
Jet/ACE gives up at that point (though there may be some retries in
there), which is probably a good thing, as the last thing you'd want
is an locking file that is reporting incorrect information for other
users.
If my memory serves, simply
unplugging ethernet while the Access application is open is enough
to cause that unsavory error.
Click to expand...

Any dropped packet during Jet/ACE communication is going to cause
the error.
I know that your Network Admin says it's not
a network problem, but if there's a funky network card on the
network that causes more disconnection/disruptions, it's enough to
trigger the errors.
Click to expand...

It can be caused by all sorts of issues, including software running
on the server that can interfere with the networking redirector.
This is even true even if the computer with the funky network
card can surf the website and use other network resources without
any apparent disruptions.
Click to expand...

The Internet is the most forgiving networking technology ever -- it
was built with the assumption that packets would be lost. And
websites are stateless, i.e., there's no bound data, so this is not
an issue.
As far as I know, the error is basically untrappable, so
prevention is the only thing you can do.
Click to expand...

Access/Jet/ACE is the canary in the coal mine. Other apps may have
no difficulties, but this is precisely because what they are doing
across the network is not nearly as complicated as what Jet/ACE does
with locking its data files for the purpose of allowing multi-user
access.
 
Amy E. Baggott said:
I have an Access Database that has run stably for a few years, but has
suddenly started throwing "Disk or Network Errors" on both the front and back
end or just freezing with no explanation. The user then has to click OK a
few dozen times before it will let you close (or just use End Task), but when
you open it back up almost immediately, it's fine. This happens at random
and just started this week. My IT Network Admin says it's not a network
problem, and I'm inclined to agree because it isn't affecting anything else
that runs on the network.

Any ideas? It's getting to be a serious pain in the arse. TNX
Click to expand...

No, it's either a hardware problem of some sort or possibly a network
driver problem. Is this happening on only one workstation or several.
If several then the problem is in the switch or the server.

Tony
 
John Spencer said:
Other possibilities would be patches to the Access software that just got
applied and has now triggering something to cause this.
Click to expand...

I've never seen Access/Jet do this.

Tony
 
I've never seen Access/Jet do this.
Click to expand...

It might be that changes in Access/Jet cause an underlying issue
elsewhere that predated the patch to suddenly become an issue. That
is, the problem was there, but only became an issue with a change of
Access/Jet executables.

I would agree that this is an unlikely source of the problem.
 
=?Utf-8?B?QW15IEUuIEJhZ2dvdHQ=?=
I have an Access Database that has run stably for a few years, but
has suddenly started throwing "Disk or Network Errors" on both the
front and back end or just freezing with no explanation. The user
then has to click OK a few dozen times before it will let you
close (or just use End Task), but when you open it back up almost
immediately, it's fine. This happens at random and just started
this week. My IT Network Admin says it's not a network problem,
and I'm inclined to agree because it isn't affecting anything else
that runs on the network.
Click to expand...

Have any new computers been added to the LAN? I had a client whose
database ran fine for years, and when they added a new laptop,
suddenly things went wonky. Upgrading the NIC drivers on the laptop
fixed the problem.

It could also be a new server, router, switch or hub, or any other
component of the network. It doesn't have to be directly between the
machine experiencing the problem and the file server where the back
end is stored -- since network packets can go through any number of
hosts and get passed on by them, all the hosts connected to the LAN
are potentially causes of "pollution" of the LAN traffic with
packets that Access/Jet don't like.
 
It is happening on multiple workstations in both the front end and the back
end (in fact I can get a pretty good guess of who's in the database by how
many shouts of, "Is something going on with the database?" I get. This just
started up last Monday. There were no changes to the network or the
workstations in the week preceding when the error started showing up.
 
Prevention how? Without knowing what's causing it, I don't see how to
prevent it.
 
I understand the frustration, but that's the unfortunate fact. I would
absolutely love to trap the error and would share it gladly but AFAIK,
it's not trappable, so you have to prevent it by monitoring the hardware
for any faults as others have suggested and they've given you few leads
to look into for identifying the cause.
 
=?Utf-8?B?QW15IEUuIEJhZ2dvdHQ=?=
It is happening on multiple workstations in both the front end and
the back end
Click to expand...

I don't understand this comment. Presumably, front ends are all
stored on the workstations, and back ends are all stored on the file
server. Why would it ever happen in a back end, given that users
shouldn't ever be opening the back ends?

Are you storing your front ends on the server?

Are you sharing front ends?

While neither of those things is a cause of the DISK OR NETWORK
ERROR, the former can aggravate the situation, since you're
unnecessarily using the network for something that should be loaded
locally (i.e., the front end), and the latter can lead to all sorts
of unpredictable errors.
(in fact I can get a pretty good guess of who's in the database by
how many shouts of, "Is something going on with the database?" I
get. This just started up last Monday. There were no changes to
the network or the workstations in the week preceding when the
error started showing up.
Click to expand...

....none that you are aware of.

Something *did* change. It doesn't have to be in the
software/hardware configurations of the workstations/servers
directly involved with your Access applications. Nor does it have to
be on your local subnet -- it can be something anywhere on the LAN
that is connected to your local subnet.

Also, keep in mind that Windows Updates if automatically applied are
constantly changing the software configuration of your workstations
and servers.

It's a terribly difficult thing to troubleshoot.
 
The front end is also stored on the server. The back end is also used as the
administrative database, containing some functionality that the
administrators use that the rest of the group has no business touching. It's
worked fine that way for years.
 
Amy E. Baggott said:
It is happening on multiple workstations in both the front end and the back
end (in fact I can get a pretty good guess of who's in the database by how
many shouts of, "Is something going on with the database?" I get.
Click to expand...

Then this tells us that the problem is in the switch to which all the
PCs connect to or the server or somewhere in between there. See if
the IT department did anything a week ago. Including someone mucking
about in the wiring closet.

Tony
 
=?Utf-8?B?QW15IEUuIEJhZ2dvdHQ=?=
The front end is also stored on the server. The back end is also
used as the administrative database, containing some functionality
that the administrators use that the rest of the group has no
business touching. It's worked fine that way for years.
Click to expand...

When you say "the" front end, do you mean that multiple users are
sharing a single front end?

If so, eliminate that, because that's the wrong way to do it. Each
user needs an individual copy of the front end, normally stored on
the user workstation (though it can be stored on the server, it's
not advisable as it introduces unnecessary network traffic).

The fact that all of it has worked fine in the past is irrelevant,
since something in the operating environment has changed and it
doesn't work now.

The first thing to do is to STOP sharing a front end, if that's what
you're doing.

Secondly, if you're not sharing the front end, try moving it to the
workstations and see if that has an effect. It would certainly take
one exposure to the network environment out of the picture.

One other thing to check would be if the linked tables are defined
with a drive letter or a UNC path. I prefer UNC paths, but I'd
suggest swapping (if it's a drive letter, change to UNC, and vice
versa). Also, you might try linking via IP address instead of UNC
name (e.g., \\192.168.1.x\Database\BackEnd.mdb). That would at least
take DNS out of the picture, which is another potential point of
failure.
 
Then this tells us that the problem is in the switch to which all
the PCs connect to or the server or somewhere in between there.
See if the IT department did anything a week ago. Including
someone mucking about in the wiring closet.
Click to expand...

Do switches/routers do automatic software patches like Windows
Update? If they do, I'd certainly turn it off if I were the sysadmin
in charge!
 
My main concern with giving everyone their own copy of the front end is
keeping them all current. I have enough trouble making sure they all have
the correct shortcuts on their desktop. Is there an easy way to push changes
to everybody's machine at once from my desk, or would I have to go from desk
to desk to make any changes (we have people on separate floors of the
building). If there is a way to make it automatic, that would be even
better, as I have a memory like a seive.

TNX
 
My main concern with giving everyone their own copy of the front end is
keeping them all current.  I have enough trouble making sure they all have
the correct shortcuts on their desktop.  Is there an easy way to push changes
to everybody's machine at once from my desk, or would I have to go from desk
to desk to make any changes (we have people on separate floors of the
building).  If there is a way to make it automatic, that would be even
better, as I have a memory like a seive.
Click to expand...

Amy,

See Tony Toew's auto updater at
http://www.autofeupdater.com/

Hope that helps
Rick
 
=?Utf-8?B?QW15IEUuIEJhZ2dvdHQ=?=
My main concern with giving everyone their own copy of the front
end is keeping them all current.
Click to expand...

You know, I've been creating Access applications for clients since
1996, and not once have I ever distributed anything but a split app.

And I've never had any issues whatsoever in getting the updates out
to the users. I've done it manually. I've emailed the updates to
each user. I've created installers to do it for them. I've used Tony
Toews's front-end updater. I've written batch files that the users
doubleclick to upgrade.

At no point have I considered this problematic, or even
inconvenient.

It is not by any stretch of the imagination an excuse for sharing a
front end.
I have enough trouble making sure they all have
the correct shortcuts on their desktop. Is there an easy way to
push changes to everybody's machine at once from my desk, or would
I have to go from desk to desk to make any changes (we have people
on separate floors of the building). If there is a way to make it
automatic, that would be even better, as I have a memory like a
seive.
Click to expand...

The easiest way for the end users is something like Tony's utility,
but that's a bit complicated to set up (though it's easier now that
Tony has a front end to set up the INI file), but setting it up is a
one-time operation, and I'm sure plenty of people can offer help on
that, including Tony himself.

You have no excuse for exposing your users to such inconvenience as
is caused by sharing a front end.
 
David W. Fenton said:
The easiest way for the end users is something like Tony's utility,
but that's a bit complicated to set up
Click to expand...

I'm going to create a wizard in the very near future for the utility.
Then forms so you can update all the INI parameters using a GUI.

Tony
 
Back
Top