Disk Or Network Error

[NEWSGROUPS]

I work for a large organization were my team has developed 2 very
substantial databases in Access 2000. These databases have been working fine
for the last 6 years with minimal issues or problems. About 1 week ago today
we have started experiencing the error "Microsoft Visual Basic Run Time
Error 3043 Disk or Network Error" just about every day around the same time
each day (activity starts to increase at this time in the databases).
Sometimes the error happens with minimal problems and others that end in a
corruption of one of the databases that can be repaired (thank god). After
this episode all seems to work fine.

Both databases have a front end that resides on the server that all users
access (I know this is not a good practice) and a back end that also resides
on the server. The server is Windows NT with all the clients running Windows
2000. We usually range about 20 or so concurrent users in the databases
which has not been any issue in the past. The company has recently upgraded
many of the client machines. When we contact our server network staff to
look into this issue they check all the server event logs and find no
reports of errors. They have even checked some of the users NIC card
settings only to discover that they are set at 100 full and not at automatic
which has been documented to cause problems.

We run a compact and repair on all databases weekly and keep the databases
clear of unused forms and other DB objects. This problem seems like it will
never go away. Does anyone have any ideas as to what this can possible be
and what we can do to resolve the problem? Any help would be much
appreciated.

Warm Regards,
Mark

[Tom van Stiphout]

On Thu, 4 Jan 2007 23:19:41 -0500, "NEWSGROUPS"
<ma***********@comcast.netwrote:

My guess is a bad NIC or network cable. Even a momentary interruption
of service can crash an Access back-end.
Use a binary trial-and-error to find out which one.

It isn't a rogue user who is trying to destroy the back-end by killing
the Access session in the middle of an update, right? I have
previously posted about solutions to this problem.

-Tom.

>I work for a large organization were my team has developed 2 very
substantial databases in Access 2000. These databases have been working fine
for the last 6 years with minimal issues or problems. About 1 week ago today
we have started experiencing the error "Microsoft Visual Basic Run Time
Error 3043 Disk or Network Error" just about every day around the same time
each day (activity starts to increase at this time in the databases).
Sometimes the error happens with minimal problems and others that end in a
corruption of one of the databases that can be repaired (thank god). After
this episode all seems to work fine.

Both databases have a front end that resides on the server that all users
access (I know this is not a good practice) and a back end that also resides
on the server. The server is Windows NT with all the clients running Windows
2000. We usually range about 20 or so concurrent users in the databases
which has not been any issue in the past. The company has recently upgraded
many of the client machines. When we contact our server network staff to
look into this issue they check all the server event logs and find no
reports of errors. They have even checked some of the users NIC card
settings only to discover that they are set at 100 full and not at automatic
which has been documented to cause problems.

We run a compact and repair on all databases weekly and keep the databases
clear of unused forms and other DB objects. This problem seems like it will
never go away. Does anyone have any ideas as to what this can possible be
and what we can do to resolve the problem? Any help would be much
appreciated.

Warm Regards,
Mark

[NEWSGROUPS]

Tom
What is meant by "Use a binary trial-and-error to find out which one". I
have relied totally on our Network people thus far.

I can't believe that it is a rouge user. In fact I have watched a couple
users processing their work in the system and then receiving the error
message before the routine completes.

Thank you,
Mark


"Tom van Stiphout" <no*************@cox.netwrote in message
news:pd********************************@4ax.com...

On Thu, 4 Jan 2007 23:19:41 -0500, "NEWSGROUPS"
<ma***********@comcast.netwrote:

My guess is a bad NIC or network cable. Even a momentary interruption
of service can crash an Access back-end.
Use a binary trial-and-error to find out which one.

It isn't a rogue user who is trying to destroy the back-end by killing
the Access session in the middle of an update, right? I have
previously posted about solutions to this problem.

-Tom.

>>I work for a large organization were my team has developed 2 very
substantial databases in Access 2000. These databases have been working
fine
for the last 6 years with minimal issues or problems. About 1 week ago
today
we have started experiencing the error "Microsoft Visual Basic Run Time
Error 3043 Disk or Network Error" just about every day around the same
time
each day (activity starts to increase at this time in the databases).
Sometimes the error happens with minimal problems and others that end in a
corruption of one of the databases that can be repaired (thank god). After
this episode all seems to work fine.

Both databases have a front end that resides on the server that all users
access (I know this is not a good practice) and a back end that also
resides
on the server. The server is Windows NT with all the clients running
Windows
2000. We usually range about 20 or so concurrent users in the databases
which has not been any issue in the past. The company has recently
upgraded
many of the client machines. When we contact our server network staff to
look into this issue they check all the server event logs and find no
reports of errors. They have even checked some of the users NIC card
settings only to discover that they are set at 100 full and not at
automatic
which has been documented to cause problems.

We run a compact and repair on all databases weekly and keep the databases
clear of unused forms and other DB objects. This problem seems like it
will
never go away. Does anyone have any ideas as to what this can possible be
and what we can do to resolve the problem? Any help would be much
appreciated.

Warm Regards,
Mark

[CDMAPoster]

NEWSGROUPS wrote:

I can't believe that it is a rouge user.

On the contrary. The one who blushes is usually the culprit :-).

James A. Fortune
CD********@FortuneJames.com

The ancient Egyptian word for donkey is pronounced something like
ee-aww.

[pietlinden]

NEWSGROUPS wrote:

Tom
What is meant by "Use a binary trial-and-error to find out which one". I
have relied totally on our Network people thus far.

I can't believe that it is a rouge user. In fact I have watched a couple
users processing their work in the system and then receiving the error
message before the routine completes.

Thank you,
Mark

binary search -
basically, you split the whole group into two halves. Then test with
each half. When you identify the half with the problem, keep testing
that half (and splitting it) until you find the one that's causing the
problem.

[David W. Fenton]

Tom van Stiphout <no*************@cox.netwrote in
news:pd********************************@4ax.com:

My guess is a bad NIC or network cable.

Let me dissent on this, as I always do.

I have never even once encountered corruption that was due to
hardware. In every situation I've encountered it has been caused by
software, either Access/Jet on the workstation or some other
software on the server.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Chuck Grimsby]

On Fri, 05 Jan 2007 15:07:36 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalidwrote:

>Tom van Stiphout <no*************@cox.netwrote in
news:pd********************************@4ax.com :

>My guess is a bad NIC or network cable.

Let me dissent on this, as I always do.

I have never even once encountered corruption that was due to
hardware. In every situation I've encountered it has been caused by
software, either Access/Jet on the workstation or some other
software on the server.

I'll dissent on your dissent, David.

I've seen it several times, and cured it by replacing a NIC.

In once case, the computer with the bad NIC wasn't the computer
opening up the database. In fact, the user running the computer
didn't have access to the folder when the DB was. They couldn't of
opened it even if they wanted to!

This is one of the reasons I have a Packet Analyzer in my tool kit.
If I can't find a reason why a MDB corrupts, out comes the Packet
Analyzer, and I can see if that's the reason.
--
Drive C: Error. (A)bort (R)etry (S)mack The Darned Thing

[David W. Fenton]

Chuck Grimsby <c.*******@worldnet.att.net.invalidwrote in
news:bf********************************@4ax.com:

On Fri, 05 Jan 2007 15:07:36 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalidwrote:

>>Tom van Stiphout <no*************@cox.netwrote in
news:pd********************************@4ax.co m:

>>My guess is a bad NIC or network cable.

Let me dissent on this, as I always do.

I have never even once encountered corruption that was due to
hardware. In every situation I've encountered it has been caused
by software, either Access/Jet on the workstation or some other
software on the server.

I'll dissent on your dissent, David.

I've seen it several times, and cured it by replacing a NIC.

Actually, I'll have to dissent from my own dissent -- I just
remembered that last summer one of my clients had the same problem.
But it was on an *old* NIC that had been running just fine for 3
years or so and it started causing problems when they dropped in a
new ThinkPad onto the network. Everybody started getting DISK OR
NETWORK ERRORS. We assumed driver problems or issues with the NIC in
the ThinkPad. We ended up swapping a different NIC into it and that
didn't change anything, so we finally swapped out the NIC in a
machine that had been running just fine on the LAN for a while and
that fixed it.

So, it seems like a software/hardware change that caused a hardware
problem to surface, one that had prevously not been a problem with
the old hardware/software environment.

In once case, the computer with the bad NIC wasn't the computer
opening up the database. In fact, the user running the computer
didn't have access to the folder when the DB was. They couldn't
of opened it even if they wanted to!

This is one of the reasons I have a Packet Analyzer in my tool
kit. If I can't find a reason why a MDB corrupts, out comes the
Packet Analyzer, and I can see if that's the reason.

I first check the Jet and Access versions and 9 times out of 10,
that's the cause with my clients -- somebody's machine has been
reverted to shipping versions of Access/Jet. This is why most of my
apps log these at startup so I can just check for the period in
question if anyone's Jet or Access versions are release versions
instead of the patched versions. Then those machines are patched and
the corruption goes away.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Chuck Grimsby <c.*******@worldnet.att.net.invalidwrote in
news:bf********************************@4ax.com:

I'll dissent on your dissent, David.

My point is not to dispute your experience, but just to remind
people not to disregard software environment in their
troubleshooting. Check the obvious first -- software is a lot easier
to troubleshoot and fix than hardware.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Tom van Stiphout]

On Fri, 05 Jan 2007 15:07:36 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalidwrote:

I've had it happen at least once every other year. Some clients have
it a lot, some never. For most going to better hardware solved the
problem.

Can you write an Access demo app that will cause this error?

-Tom.

>Tom van Stiphout <no*************@cox.netwrote in
news:pd********************************@4ax.com :

>My guess is a bad NIC or network cable.

Let me dissent on this, as I always do.

I have never even once encountered corruption that was due to
hardware. In every situation I've encountered it has been caused by
software, either Access/Jet on the workstation or some other
software on the server.

[David W. Fenton]

Tom van Stiphout <no*************@cox.netwrote in
news:bs********************************@4ax.com:

On Fri, 05 Jan 2007 15:07:36 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalidwrote:

>>Tom van Stiphout <no*************@cox.netwrote in
news:pd********************************@4ax.co m:

>>My guess is a bad NIC or network cable.

Let me dissent on this, as I always do.

I have never even once encountered corruption that was due to
hardware. In every situation I've encountered it has been caused
by software, either Access/Jet on the workstation or some other
software on the server.

I've had it happen at least once every other year. Some clients
have it a lot, some never. For most going to better hardware
solved the problem.

Can you write an Access demo app that will cause this error?

Huh? It's not application-specific. It's caused by bad versions of
Access and Jet, or server-side software that somehow interferes with
Jet's use of files stored on that server. It has *zilch* to do with
what is in the Access app.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[NEWSGROUPS]

David,
I don't know if I can truly blame this on Access this time as the database
has worked almost error free for about 6 years. I have a routine that logs
the version of JET on log on to a table and all users are up to date or at
least running the same version. Also the databases run a good portion of the
day without the error happening with all modules, forms, etc having been
transacted on all day prior to said problems.

Do you have any other Access/Software ideas that I can check?

Mark

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

Tom van Stiphout <no*************@cox.netwrote in
news:pd********************************@4ax.com:

>My guess is a bad NIC or network cable.

Let me dissent on this, as I always do.

I have never even once encountered corruption that was due to
hardware. In every situation I've encountered it has been caused by
software, either Access/Jet on the workstation or some other
software on the server.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Chuck Grimsby]

From a message in this newsgroup back in 2001:

Arvin Meyer's Top 5 list for the causes of corruption:

Almost all corruption is caused by a failure during a write.

The #1 reason for corruption is users not properly shutting down. I'd
say that is the cause in well over 90% of the cases (as high as
99%). If something hangs on the machine, users reboot. If they want
to go home, or to lunch, they shutdown improperly. They walk away
from their desks during long operations, and anything can happen.
The #2 reason is power fluctuations or failure. Do you have UPS's on
the workstations?
The #3 reason is a malfunctioning NIC. No, re-sending a packet won't
necessarily correct the problem, a corrupted bit can be re-sent, and
TCP/IP doesn't check whether the bits are correct in each frame
sent, merely that the frame has integrity.
3a. Bad cabling (did someone trip over a wire causing a loose
connection?)
The #4 cause is a bad video card or corrupted driver. (Try updating
the driver first, then replace the card if that doesn't fix things.)
The #5 cause is bad code. Something in the code doesn't work right
which can prevent a write from consummating properly.

-------------------------------------------------------------------

To which David W. Fenton always added (and I agree with!):
Hotfixes on NT Servers. (Avoid them like the plague!)

Some Server Patches and Service Packs on NT Servers have also
caused corruption problems.

On Novell Servers, make sure the Locks are set as high as possible.
(There's a KB article on this, but I forget which one.)

If you can, get rid of IPX/SPX. (KB Article Q165351)

Virus Protection can also cause corruption.
On Sat, 6 Jan 2007 17:08:35 -0500, "NEWSGROUPS" <he******@yahoo.com>
wrote:

>David,
I don't know if I can truly blame this on Access this time as the database
has worked almost error free for about 6 years. I have a routine that logs
the version of JET on log on to a table and all users are up to date or at
least running the same version. Also the databases run a good portion of the
day without the error happening with all modules, forms, etc having been
transacted on all day prior to said problems.

Do you have any other Access/Software ideas that I can check?

Mark

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0 .1...

>Tom van Stiphout <no*************@cox.netwrote in
news:pd********************************@4ax.com :

>>My guess is a bad NIC or network cable.

Let me dissent on this, as I always do.

I have never even once encountered corruption that was due to
hardware. In every situation I've encountered it has been caused by
software, either Access/Jet on the workstation or some other
software on the server.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

['69 Camaro]

Hi, Mark.

just about every day around the same time each day (activity starts to
increase at this time in the databases).

Nearly every day at about the same time, you say? Coincidentally when the
network activity becomes heavier? I'd look at the obvious reasons first,
but I'd also look at the non-obvious coincidences, too. Such as the network
error occurs half an hour before the managers' "beginning of the year"
meetings and someone unplugs a certain plug "for just a second" to plug in a
second coffee pot, or a work crew arrives and one of them unplugs a certain
plug "for just a second" to make room to plug in his electrical equipment.
If it's not human intervention, I'd look for mechanical intervention, such
as a heater or air conditioning coming on and overloading the electrical
system, causing a brown-out for a split second, which happens in older
buildings that weren't designed to house so many computer stations in the
same office space, and haven't yet been upgraded enough to meet present
requirements.

Both databases have a front end that resides on the server that all users
access (I know this is not a good practice)

You're asking for trouble. Just because it hasn't caused corruption
problems in the past doesn't mean it can't start at any time. The Access
development team has determined that the number one cause of Access database
corruption is multiple users sharing the front end (or unsplit file) from
across the network.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
"NEWSGROUPS" <ma***********@comcast.netwrote in message
news:g7******************************@comcast.com. ..

>I work for a large organization were my team has developed 2 very
substantial databases in Access 2000. These databases have been working
fine for the last 6 years with minimal issues or problems. About 1 week ago
today we have started experiencing the error "Microsoft Visual Basic Run
Time Error 3043 Disk or Network Error" just about every day around the same
time each day (activity starts to increase at this time in the databases).
Sometimes the error happens with minimal problems and others that end in a
corruption of one of the databases that can be repaired (thank god). After
this episode all seems to work fine.

Both databases have a front end that resides on the server that all users
access (I know this is not a good practice) and a back end that also
resides on the server. The server is Windows NT with all the clients
running Windows 2000. We usually range about 20 or so concurrent users in
the databases which has not been any issue in the past. The company has
recently upgraded many of the client machines. When we contact our server
network staff to look into this issue they check all the server event logs
and find no reports of errors. They have even checked some of the users
NIC card settings only to discover that they are set at 100 full and not
at automatic which has been documented to cause problems.

We run a compact and repair on all databases weekly and keep the databases
clear of unused forms and other DB objects. This problem seems like it
will never go away. Does anyone have any ideas as to what this can
possible be and what we can do to resolve the problem? Any help would be
much appreciated.

Warm Regards,
Mark

[David W. Fenton]

"NEWSGROUPS" <he******@yahoo.comwrote in
news:0b******************************@comcast.com:

I don't know if I can truly blame this on Access this time as the
database has worked almost error free for about 6 years. I have a
routine that logs the version of JET on log on to a table and all
users are up to date or at least running the same version. Also
the databases run a good portion of the day without the error
happening with all modules, forms, etc having been transacted on
all day prior to said problems.

But what about the version of Access? At this stage, most versions
of Windows out there have been updated to at least Jet SP6 or later
(because Jet is used in Active Directory, it's updated with the OS),
so I haven't seen a Jet reversion in quite a long time.

But Access can easily revert by running a re-install, so I also
record the version of the MSAccess.exe.

Do you have any other Access/Software ideas that I can check?

The server is the other location where software changes can cause
problems. If anything has been installed on the server just before
the problem developed, that is a place to start looking. In the case
where I had that situation, the problem developed 90 minutes after
the software was installed on the server, and went away as soon as
we backed it out (it wasn't needed anyway *sigh*).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Chuck Grimsby <c.*******@worldnet.att.net.invalidwrote in
news:sc********************************@4ax.com:

If you can, get rid of IPX/SPX.

This is not really much of an issue any more and neither Windows
workstation nor Windows Server installations default to installing
it. I would expect it to be an issue only in situations where there
has been a use of Novell servers in the past.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Chuck Grimsby <c.*******@worldnet.att.net.invalidwrote in
news:sc********************************@4ax.com:

If you can, get rid of IPX/SPX.

Oh, and Novell with version 4.something added TCP/IP as a native
protocol, so you don't even need IPX/SPX in a Novell environment any
more.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[breadon]

Getting a packet analyser sounds like a good idea. In my experience
'Disk or Network Error' does tend to be hardware related. Sometimes I
have been able to show these types of problem using the ubiquitous
'ping' command line utility.

Example commands:

ping myhostname

OR

ping -l 65500 myhostname

The first command uses the smaller default packet size and is a less
vigorous test. Run ping on the machine that is suffering from the
network problem and supply the name of the computer where the 'server'
mdb file resides.

Be aware that 'ping' is a very crude networking test. Support can not
dispute that a problem exists if you can demonstrate ping failing. If
it passes a 'ping' test it does NOT mean that there is NO network
problem. The merit of the test is that ping is a ubiquitous utility
that has been available on all the networking pc's that I have had need
of it.

[John Mishefske]

NEWSGROUPS wrote:

David,
I don't know if I can truly blame this on Access this time as the database
has worked almost error free for about 6 years. I have a routine that logs
the version of JET on log on to a table and all users are up to date or at
least running the same version. Also the databases run a good portion of the
day without the error happening with all modules, forms, etc having been
transacted on all day prior to said problems.

Do you have any other Access/Software ideas that I can check?

Mark
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message

>>Tom van Stiphout <no*************@cox.netwrote in

>>>My guess is a bad NIC or network cable.

Let me dissent on this, as I always do.

I have never even once encountered corruption that was due to
hardware. In every situation I've encountered it has been caused by
software, either Access/Jet on the workstation or some other
software on the server.

I recall this error when I installed Visio 2002 on a PC with Office 2000 installed. Cause
was a version mis-match in a DLL somewhere. I'm sure there is a MSKB on that issue.

Is it possible someone installed a MS package of a different version than the currently
installed Office/Access installation?

mskb - http://support.microsoft.com/kb/304548

--
'---------------
'John Mishefske
'---------------