We have an Access DB on a file server with about 10 people connecting via a network. We occasionally get an error (3043 - Disk or Network Error) that randomly starts (we can go weeks without) and then repeats about every hour, a random number of times (anywhere from once to about five times) before it quits. It is usually on a particular workstation, but not always. However, there are some workstations that NEVER get the error. We have replaced most (but not all) cables and network components (they were old anyway) and it did not help. We made sure to replace the components in the workstation that experiences this problem the most. We have tried the TMP directory resolution, and a few others floating around in posts, but it still occurs. To try and isolate the issue, we shut the offending computer down for 15 mins to see if it affected the hour timing, and although most of the time it did (an hour and fifteen minutes later another error) a couple of times the error occurred 60 mins later regardless. Any suggestions would be greatly appreciated as this is driving us crazy. We can never reproduce the error, and the fact that it can go days or weeks without happening makes trying resolutions difficult. Hopefully someone has experienced this behavior before?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Error 3043 MSAccess Disk or Network Errors
- Thread starter MJSNet
- Start date
I have not seen that one but I have some ideas...
I am of course assuming you do not have any malware.
When I upgraded to Windows Server 2003 I noticed a significant peformance hit to Jet databases. I think oppurtunistic locking being on had something to do with it.
Microsoft article id: 296264
I also isolated the Jet databases on a partition so they would not have to contend with the constant saving of other types of files to disk and therefore deal with more file fragmentation.
I believe both these solutions may help your situation as well as regular compact and repair of the database files in question.
I can't say I have seen a real network issue that has effected only JET. Obviously, drivers and firmware should be current. Gigabit ethernet seems to be particularly suseptable to acting up with old drivers (Dell in my case).
You may also consider trying to remove switch hops for Access users or at least the high transaction users (writes). My environment is not big enough to have multiple subnets, but I suspect that clients spanning subnets may generate problems. In the same subnet, the network collision detection on the same NIC server side may prevent or reduce concurrent write conflicts. Ironic, on the one hand I am trying to elminate latency and on the other cause it.
Although it is a performance hit until the front end is adjusted, you may consider using SQL Server as a Backend.
Long shot but, perhaps a security App is messing with read and writes?
You may try swapping computers with a user that does not use the system and see if it fixes the problem.
That's all the ideas I could come up with, I hope one helps.
I am of course assuming you do not have any malware.
When I upgraded to Windows Server 2003 I noticed a significant peformance hit to Jet databases. I think oppurtunistic locking being on had something to do with it.
Microsoft article id: 296264
I also isolated the Jet databases on a partition so they would not have to contend with the constant saving of other types of files to disk and therefore deal with more file fragmentation.
I believe both these solutions may help your situation as well as regular compact and repair of the database files in question.
I can't say I have seen a real network issue that has effected only JET. Obviously, drivers and firmware should be current. Gigabit ethernet seems to be particularly suseptable to acting up with old drivers (Dell in my case).
You may also consider trying to remove switch hops for Access users or at least the high transaction users (writes). My environment is not big enough to have multiple subnets, but I suspect that clients spanning subnets may generate problems. In the same subnet, the network collision detection on the same NIC server side may prevent or reduce concurrent write conflicts. Ironic, on the one hand I am trying to elminate latency and on the other cause it.
Although it is a performance hit until the front end is adjusted, you may consider using SQL Server as a Backend.
Long shot but, perhaps a security App is messing with read and writes?
You may try swapping computers with a user that does not use the system and see if it fixes the problem.
That's all the ideas I could come up with, I hope one helps.
- Thread starter
- #3
Thanks for the ideas lameid!
No malware; we have restricted internet access, also.
We DID upgrade to Server 2003, but from a Snap! server that had a RAID drive fail, and of course, was causing DoN errors for everyone. Actually noticed an improvement. I will try the solution in the KB article concerning op-locks. What is really annoying and confusing is the timing when it does start. Every hour, and only a number of consecutive hours until it stops, sometimes for days or weeks! It will also happen a couple of days in a row. Hardly ever is it from punch in to punch out, though. And the number of active users varies from a one or a few to maybe 6 at most at one time.
Great idea about the partition in any scenario.
We do a repair and compact whenever we get a DoN because we noticed more users start to get them if we don't (that and the non-existent table that does exist error.) Religious about that.
Disabled Norton Antivirus Corp Edition, still happened.
Although the server and switch are gigabit, all terminals are 100. We recently upgraded the switch suspecting it may be the issue. Was a 100 before. The terminal with problems is local on the same switch as the server.
SQL Server is in the (not so near) future.
Swapped computers today to see if it follows the computer. I suspect it will.
Even made sure the NIC wasn't going to sleep!
Very, very frustrating. Thanks again, I greatly appreciate any and all longshots as I have run out of 'em myself!
No malware; we have restricted internet access, also.
We DID upgrade to Server 2003, but from a Snap! server that had a RAID drive fail, and of course, was causing DoN errors for everyone. Actually noticed an improvement. I will try the solution in the KB article concerning op-locks. What is really annoying and confusing is the timing when it does start. Every hour, and only a number of consecutive hours until it stops, sometimes for days or weeks! It will also happen a couple of days in a row. Hardly ever is it from punch in to punch out, though. And the number of active users varies from a one or a few to maybe 6 at most at one time.
Great idea about the partition in any scenario.
We do a repair and compact whenever we get a DoN because we noticed more users start to get them if we don't (that and the non-existent table that does exist error.) Religious about that.
Disabled Norton Antivirus Corp Edition, still happened.
Although the server and switch are gigabit, all terminals are 100. We recently upgraded the switch suspecting it may be the issue. Was a 100 before. The terminal with problems is local on the same switch as the server.
SQL Server is in the (not so near) future.
Swapped computers today to see if it follows the computer. I suspect it will.
Even made sure the NIC wasn't going to sleep!
Very, very frustrating. Thanks again, I greatly appreciate any and all longshots as I have run out of 'em myself!
For what it is worth a few years ago when we used Symantec Aniti Virus we did not have real problems with it (Win2k3 Server, Acc97). Although for the money, I like Grisoft's AVG. For better and worse we moved to Acc2003 but had switched to AVG since.
When I was looking at perfomance I also vaguely remember something about client side timeout settings or other network settings that would tend to effect reading and writing large files more. It is at least something to research if nothing else helps.
2 more thoughts, you might try setting the speed and duplex on the NIC's and if possible the switch to the max common setting to remove any problems with auto negotiating.
When I was looking at perfomance I also vaguely remember something about client side timeout settings or other network settings that would tend to effect reading and writing large files more. It is at least something to research if nothing else helps.
2 more thoughts, you might try setting the speed and duplex on the NIC's and if possible the switch to the max common setting to remove any problems with auto negotiating.
Oops... And the second thought is, your network drop itself maybe bad or flaky.
One more jumped at me... Maybe there is interference. So if the user is doing a lot in the database and a fan or microwave is on, then you get the problem. Other possible sources of interference: vacuum, cell phone, power tools, interference put over electric line from any electronics device and crosstalking over nearby network wire.
Maybe the problem is a bad NIC in a computer causing some sort of storm. Any Sales people always in town when the problems occur? More ironic, maybe the president only turns his computer on sometimes (mine does not even have a computer).
One more jumped at me... Maybe there is interference. So if the user is doing a lot in the database and a fan or microwave is on, then you get the problem. Other possible sources of interference: vacuum, cell phone, power tools, interference put over electric line from any electronics device and crosstalking over nearby network wire.
Maybe the problem is a bad NIC in a computer causing some sort of storm. Any Sales people always in town when the problems occur? More ironic, maybe the president only turns his computer on sometimes (mine does not even have a computer).
- Status
Similar threads
- Question
