"Disk or network error"

[David W. Fenton]

I'm no stranger to this error message, but I have a client who is
experiencing it, but, fortunately, without any actual data
corruption, and it's driving them made. Their inability to grasp
that the cause is fundamentally a networking problem is also making
me pull my hair out.

Some history:

The network is composed of five computers dating back to 1995, each
purchased one at a time, and each having a different OS, etc. Until
the recent purchase of an IBM laptop, the network was stable with
only two machines, a Win2K desktop (which was the peer-to-peer file
server) and a Win98 desktop (the primary workstation).

Previous to that, the Win98 desktop had been the file server, and
the other workstation was a Win95 box. That setup worked just fine.

During that time a Win98 laptop was purchased, but it was hardly
ever used, so I can't say whether or not it had any problems
connecting to the network.

When we got the Win2K box, I set it up as I always do, using TCP/IP
networking, and the Win98 workstation had trouble connecting at
anything but really slow speeds to the Win2K box. I eventually
installed NETBEUI on both boxes and then things worked fast (don't
let anyone tell you that NETBEUI is a bad networking protocol!).

Recently, a new IBM T42 was purchased to be used as primary
workstation for the boss, and the Win2K box was retired for use as
principle workstation. So, the new configuration was:

WinXP laptop --> Win2K P2P server

Previous was:

Win98 desktop --> Win2K P2P server (TCP/IP + NETBEUI)

Previous to that was:

Win95 desktop --> Win98 P2P server (no NETBEUI)

Also, in the current situation, with:

WinXP laptop --> Win2K P2P server

the Win98 laptop has also been revived.

When I set up the new WinXP laptop, I removed NETBEUI from
everything. But after that, both laptops (WinXP and Win98) have been
experiencing intermittent problems with network connectivity --
things start out great but after a few minutes (5-20), "disk or
network error" pops up. If the user then tries to access network
resources by some other method (My Network Places, etc.), they may
or may not get through (about 2/3s of the time, it succeeds, but the
remainder of times, it, too fails).

But in none of these cases has the data file ever been corrupted
(front ends on all the workstations, data file only on the P2P
server).

Also, when things *are* working on WinXP, the network is *slow*,
similar to the way things were failing with the Win98 workstation
connecting to the Win2K P2P server. Since the old situation seemed
to have been worked around by installing NETBEUI, we tried that with
the current batch of machines, but it didn't solve the problem (note
that with the old network problems, we weren't getting "disk or
network error," just poor performance).

We've replaced all the wiring. We've swapped hubs. We're currently
downloading all new network drivers, and looking into turning off
all AV scanning of MDBs.

Any other ideas what might be causing "disk or network error" with
no corruption, and no complaints from any other applications?

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

[David W. Fenton]

One crucial thing I failed to mention: this is an entirely Access 97
setup, so I don't think OpLocks could have anything to do with it,
as that's something that started being an issue only with Access 2K,
right?

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

[Tom van Stiphout]

On Fri, 01 Apr 2005 20:33:38 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

I think that rather than software, you need to think about failing
hardware. Perhaps a NIC, a hub (port), or a cable.

-Tom.

One crucial thing I failed to mention: this is an entirely Access 97
setup, so I don't think OpLocks could have anything to do with it,
as that's something that started being an issue only with Access 2K,
right?

[David W. Fenton]

Tom van Stiphout <no*************@cox.net> wrote in
news:dr********************************@4ax.com:

On Fri, 01 Apr 2005 20:33:38 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

One crucial thing I failed to mention: this is an entirely Access
97 setup, so I don't think OpLocks could have anything to do with
it, as that's something that started being an issue only with
Access 2K, right?

I think that rather than software, you need to think about failing
hardware. Perhaps a NIC, a hub (port), or a cable.

Well, the only hardware that has changed is the addition of a new
laptop, and it's exhibiting the same symptoms as a laptop that is 4
years old, so that would tend to make me think that the problem was
not hardware.

I also don't have any experience with NICs going bad over time --
they are either bad or they aren't.

If the problem machines were desktops, we'd have swapped out the
NICs right off, but they aren't swappable (I think both are onboard
the laptop motherboards).

IBM is not interested in discussing NIC troubleshooting.

The Dell laptop is long out of warranty.

I'm also quite prejudiced against hardware failure as a cause of
these kinds of errors, as I have never had a single instance of this
kind of problem that was *not* software-based. Of course, this could
be the time it's hardware.

All but one of the cables has already been replaced with new (I told
them to switch all cables, but they aren't too bright, and switched
all of them except the one that was involved in every network
transaction, the one from the hub to the P2P server).

I despair over trying to identify a failing NIC given the
circumstances (I can't get to the client easily, and they NICs can't
be swapped out). I do believe there is a hub (it may be an
auto-sensing switch, which serves no purpose on a network of this
size, but the husband of the boss is one of those
knows-just-enough-to-be-dangerous types) in addition to a Linksys
cable/DSL router with 4 ports. I don't know what's plugged into
what, though. The Linksys box is new, the hub/switch, I don't know.

Another reason I suspect it's *not* hardware is the complete lack of
corruption. This isn't any kind of specially-designed app with
careful connection management -- it's based on the first major
Access app I ever created for a client. That means the design is
HIDEOUS. :) And it uses forms bound to entire tables (though it is,
at least, a SQL string in the recordsource). I would think it would
be very prone to corruption if it lost the network connection, but
it doesn't seem to be.

That makes me suspect a non-hardware issue.

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

[Alan Webb]

David,
Dunno if this is related, but . . . My sister's pretty decent 3Com NIC that
shipped with her Gateway when it was new stopped talking to her ISP's
broadband connection. It was a 10/100 card like most are these days and
when I plugged it into my switch it connected and communicated fine. For
grins & giggles we went out and bought a Netgear FA311 on sale and swapped
it out for the 3Com NIC and plugged that in to her broadband connection.
Voila, connection solid & fast. The 3Com card was not bad but something on
the ISP's side had changed so that this NIC's chipset wasn't playing nice
with her ISP. The Netgear NIC had a newer chipset and that fixed it.
And . . . You can add an additional NIC to a computer that has one on the
motherboard. Replacement NIC's are around $20.00 to $25.00 new, sometimes
much cheaper if there is a sale going. I'd gamble $20.00 of my customer's
money if it would help me troubleshoot this.
--
Alan Webb
kn*******@SPAMhotmail.com
"It's not IT, it's IS
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.90...

Tom van Stiphout <no*************@cox.net> wrote in
news:dr********************************@4ax.com:

On Fri, 01 Apr 2005 20:33:38 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

One crucial thing I failed to mention: this is an entirely Access
97 setup, so I don't think OpLocks could have anything to do with
it, as that's something that started being an issue only with
Access 2K, right?

I think that rather than software, you need to think about failing
hardware. Perhaps a NIC, a hub (port), or a cable.

Well, the only hardware that has changed is the addition of a new
laptop, and it's exhibiting the same symptoms as a laptop that is 4
years old, so that would tend to make me think that the problem was
not hardware.

I also don't have any experience with NICs going bad over time --
they are either bad or they aren't.

If the problem machines were desktops, we'd have swapped out the
NICs right off, but they aren't swappable (I think both are onboard
the laptop motherboards).

IBM is not interested in discussing NIC troubleshooting.

The Dell laptop is long out of warranty.

I'm also quite prejudiced against hardware failure as a cause of
these kinds of errors, as I have never had a single instance of this
kind of problem that was *not* software-based. Of course, this could
be the time it's hardware.

All but one of the cables has already been replaced with new (I told
them to switch all cables, but they aren't too bright, and switched
all of them except the one that was involved in every network
transaction, the one from the hub to the P2P server).

I despair over trying to identify a failing NIC given the
circumstances (I can't get to the client easily, and they NICs can't
be swapped out). I do believe there is a hub (it may be an
auto-sensing switch, which serves no purpose on a network of this
size, but the husband of the boss is one of those
knows-just-enough-to-be-dangerous types) in addition to a Linksys
cable/DSL router with 4 ports. I don't know what's plugged into
what, though. The Linksys box is new, the hub/switch, I don't know.

Another reason I suspect it's *not* hardware is the complete lack of
corruption. This isn't any kind of specially-designed app with
careful connection management -- it's based on the first major
Access app I ever created for a client. That means the design is
HIDEOUS. :) And it uses forms bound to entire tables (though it is,
at least, a SQL string in the recordsource). I would think it would
be very prone to corruption if it lost the network connection, but
it doesn't seem to be.

That makes me suspect a non-hardware issue.

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

[Tom van Stiphout]

On Sat, 02 Apr 2005 20:01:03 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

You're going about it in a thoughtful manner, so you should be able to
find the problem. I have seen cables fail on several occasions. I've
also seen a hub fail intermittently. I agree with you that such
failures typically result in corruptions, except if your app is mostly
a reporting system and few adds/updates occur.

Of course when swapping out a NIC you're typically also swapping out
device drivers and who knows what, so it's not a pure hardware swap.

I fully agree with your prev post that NETBEUI is a great protocol for
small LANs, and I have complained to MSFT that they took it out of
WinXP. Their excuse is that it is old and limited. TCP/IP is probably
just as old, and the limitations are a strength in small networks.

-Tom.

<clip>

[David W. Fenton]

"Alan Webb" <kn*****@hotmail.com> wrote in
news:jP********************@comcast.com:

Dunno if this is related, but . . . My sister's pretty decent
3Com NIC that shipped with her Gateway when it was new stopped
talking to her ISP's broadband connection. It was a 10/100 card
like most are these days and when I plugged it into my switch it
connected and communicated fine. For grins & giggles we went out
and bought a Netgear FA311 on sale and swapped it out for the 3Com
NIC and plugged that in to her broadband connection. Voila,
connection solid & fast. The 3Com card was not bad but something
on the ISP's side had changed so that this NIC's chipset wasn't
playing nice with her ISP. The Netgear NIC had a newer chipset
and that fixed it. . . .
But it could have been the drivers.
. . . And . . . You can add an additional NIC to a
computer that has one on the motherboard. Replacement NIC's are
around $20.00 to $25.00 new, sometimes much cheaper if there is a
sale going. I'd gamble $20.00 of my customer's money if it would
help me troubleshoot this.

The problem machines are laptops, so it's not that simple or cheap.

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

[David W. Fenton]

Tom van Stiphout <no*************@cox.net> wrote in
news:41********************************@4ax.com:

On Sat, 02 Apr 2005 20:01:03 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

You're going about it in a thoughtful manner, so you should be
able to find the problem. I have seen cables fail on several
occasions. I've also seen a hub fail intermittently. I agree with
you that such failures typically result in corruptions, except if
your app is mostly a reporting system and few adds/updates occur.
This is app has lots of data editing in bound forms. My experience
with hardware errors says that it's a perfect candidate for
corruption each time the connection is lost, but it's not happening.

It does appear that the connection is being lost during idle time.
That is, the user is working with no problems, then turns to
something else, and when they come back, the error message has
popped up. I don't know what to make of that.
Of course when swapping out a NIC you're typically also swapping
out device drivers and who knows what, so it's not a pure hardware
swap.
The problem its that it's laptops, and add-on NICs are not as cheap
or as easy to come by as NICs for desktops. I've got 3 or 4 NICs
just lying around my apartment that I could use for testing if they
were desktops.
I fully agree with your prev post that NETBEUI is a great protocol
for small LANs, and I have complained to MSFT that they took it
out of WinXP. Their excuse is that it is old and limited. TCP/IP
is probably just as old, and the limitations are a strength in
small networks.

You can install on WinXP. You just need to copy files from the
VALUADD folder of your WinXP installation CD. The KB article is
here:

http://support.microsoft.com/kb/301041/

This article:

http://support.microsoft.com/kb/306059/

Gives their lame excuse for why:

Support for the NetBEUI network protocol has been discontinued
in Windows XP. This protocol is not available to install in
Windows XP. The NetBEUI protocol was developed in 1985. It is
used by network operating systems such as Microsoft LAN Manager,
Microsoft Windows for Workgroups, Microsoft Windows 95, and
Microsoft Windows NT. The NetBEUI protocol implements the OSI
LLC2 protocol, and is a non-routable protocol.

There's no real reason given there, except the implied assumption
that because it's old, it's no good, or because that it's
unacceptable simply because it's non-routable. Non-routability is A
FEATURE, not a bug!

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

[Darryl Kerkeslager]

"David W. Fenton" <dX********@bway.net.invalid> wrote

It does appear that the connection is being lost during idle time.
That is, the user is working with no problems, then turns to
something else, and when they come back, the error message has
popped up. I don't know what to make of that.

Consider that it may not be idle time - perhaps users have switched to a
different program, and your problem is actually caused by an
action/interaction with another program.

--
Darryl Kerkeslager

Power corrupts.
Absolute power corrupts absolutely.
Knowledge is power.
See www.adcritic.com/interactive/view.php?id=5927

[Ronald W. Roberts]

David W. Fenton wrote:

Tom van Stiphout <no*************@cox.net> wrote in
news:41********************************@4ax.com :

On Sat, 02 Apr 2005 20:01:03 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

You're going about it in a thoughtful manner, so you should be
able to find the problem. I have seen cables fail on several
occasions. I've also seen a hub fail intermittently. I agree with
you that such failures typically result in corruptions, except if
your app is mostly a reporting system and few adds/updates occur.

This is app has lots of data editing in bound forms. My experience
with hardware errors says that it's a perfect candidate for
corruption each time the connection is lost, but it's not happening.

It does appear that the connection is being lost during idle time.
That is, the user is working with no problems, then turns to
something else, and when they come back, the error message has
popped up. I don't know what to make of that.

Of course when swapping out a NIC you're typically also swapping
out device drivers and who knows what, so it's not a pure hardware
swap.

The problem its that it's laptops, and add-on NICs are not as cheap
or as easy to come by as NICs for desktops. I've got 3 or 4 NICs
just lying around my apartment that I could use for testing if they
were desktops.

I fully agree with your prev post that NETBEUI is a great protocol
for small LANs, and I have complained to MSFT that they took it
out of WinXP. Their excuse is that it is old and limited. TCP/IP
is probably just as old, and the limitations are a strength in
small networks.

You can install on WinXP. You just need to copy files from the
VALUADD folder of your WinXP installation CD. The KB article is
here:

http://support.microsoft.com/kb/301041/

This article:

http://support.microsoft.com/kb/306059/

Gives their lame excuse for why:

Support for the NetBEUI network protocol has been discontinued
in Windows XP. This protocol is not available to install in
Windows XP. The NetBEUI protocol was developed in 1985. It is
used by network operating systems such as Microsoft LAN Manager,
Microsoft Windows for Workgroups, Microsoft Windows 95, and
Microsoft Windows NT. The NetBEUI protocol implements the OSI
LLC2 protocol, and is a non-routable protocol.

There's no real reason given there, except the implied assumption
that because it's old, it's no good, or because that it's
unacceptable simply because it's non-routable. Non-routability is A
FEATURE, not a bug!

David,

Look at the power option of the computer. A sleep setting on the hard
drive will cause this error.

Ron

--
Ronald W. Roberts
Roberts Communication
rw*@robcom.com

[David W. Fenton]

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:z6********************@comcast.com:

"David W. Fenton" <dX********@bway.net.invalid> wrote

It does appear that the connection is being lost during idle
time. That is, the user is working with no problems, then turns
to something else, and when they come back, the error message has
popped up. I don't know what to make of that.

Consider that it may not be idle time - perhaps users have
switched to a different program, and your problem is actually
caused by an action/interaction with another program.

I meant idle time within Access, not on the network.

What kind of programs do you think might be doing something that
would cause the network connection to be dropped? This is a plain
vanilla setup, with Office and Pegasus Mail being just about the
only programs being used on these PCs.

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

[David W. Fenton]

"Ronald W. Roberts" <rw*@robcom.com> wrote in
news:11*************@corp.supernews.com:

Look at the power option of the computer. A sleep setting on the
hard drive will cause this error.

<lightbulb state="on">
Thank you!
</lightbulb>

Good point, as both machines are laptops, and this could very well
be an issue.

I used to check power settings all the time (and turn off absolutely
everything, because power saving settings were just never robust
enough), but I might have missed that on these machines.

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

[David W. Fenton]

"Ronald W. Roberts" <rw*@robcom.com> wrote in
news:11*************@corp.supernews.com:

Look at the power option of the computer. A sleep setting on the
hard drive will cause this error.

Just noticing on my own system that my NIC has it's own POWER
MANAGEMENT tab, completely independent of the settings in the
Control Panel POWER OPTIONS tool. That would be something I would
have missed during setup of each of these PCs, as I didn't know it
existed!

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

[Darryl Kerkeslager]

"David W. Fenton" <dX********@bway.net.invalid> wrote

What kind of programs do you think might be doing something that
would cause the network connection to be dropped? This is a plain
vanilla setup, with Office and Pegasus Mail being just about the
only programs being used on these PCs.

Other database programs, firewalls, or any other program that uses the
network heavily. But it sounds like that's not it. 'nother dead end.
--
Darryl Kerkeslager

Power corrupts.
Absolute power corrupts absolutely.
Knowledge is power.
See www.adcritic.com/interactive/view.php?id=5927

[David W. Fenton]

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:eI********************@comcast.com:

"David W. Fenton" <dX********@bway.net.invalid> wrote

What kind of programs do you think might be doing something that
would cause the network connection to be dropped? This is a plain
vanilla setup, with Office and Pegasus Mail being just about the
only programs being used on these PCs.

Other database programs, firewalls, or any other program that uses
the network heavily. But it sounds like that's not it. 'nother
dead end.

Well, I'll revisit the issue later if other things don't work out,
as all I've done is asked questions about things like music
downloading and the like. That oughtn't be an issue, as the
bottleneck for that would be the router that connects them to the
Internet (1.5mbps or less), not the bandwidth on the whole network
itself (which is 100BaseT across the board).

But it's possible there's something out there.

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