Network access was interrupted

[sphere_monk]

Hi everyone,

Our office has recently been receiving a sporadic series of "Network access was interrupted..." errors in our Access 2007 databases. I've been troubleshooting this problem for approximately 6 months and am at the end of my rope. I was wondering if anyone had any advice. Here are the facts.

Environment:

• 4 databases, 3 split fe/be, 1 just a db with shared tables in it.
• Windows 2003 Server Network, no wireless, no VPNs or remote users.
• 10 Windows XP users, all with a copy of at least 1 of the 3 fe's on their clients (maybe more if authorized).
• Any of the 3 fe's link to its specific be and the shared db.
• The dbs are large, some be's up to 1 gig after compacting.
• Client network drives are mapped using drive letters.
• All the fe dbs have a menu that keeps a table open at all times.

Situation:

• Everyone gets the error, sometimes.
• Some people get the error in the same form, at the same place, every time for a couple days or so, then it's gone.
• If you get the error, it shuts down every db you may have open
• It's sporadic. It seems to happen less if there are less demands on the db
• It seems to have started when the network administrator moved our primary domain controller to another server. (He swears that's not the problem).
• It always seems to happen when the form is trying to retrieve records

What I've done:

• When the problem first occurred, the fe's were being shared on the server. They have been distributed to the clients.
• The be db's have been moved from a storage device attached to the server to the server drive itself.
• We have purchased a new client for a user that, at one point, was the only one having problems. She hasn't had problems since (one week) but now other people are again.
• I've been compacting more frequently. It does not help at all.

The biggest problem, I know, was that the fe dbs had been being shared by all the users. That was completely my fault. We had not been experiencing errors so I had put off the change WAY longer than I should have (I wear too many hats at this place).

The fe's are now distributed and have been for a month. We're still experiencing these maddening interruptions. Is it possible that the operation of the fe's shared has in some way comprimised the data so that compacting does not repair it? Or is it more likely that it is a network issue?

Any suggestions or guidance would be greatly appreciated. Thanks!

 

[Galaxiom]

Could be a fault in the Ethernet port of the server or a network switch. I would try putting another network card in it.

 

[sphere_monk]

That sounds good to me. I'll tell the network guy to buy a new switch and replace the NIC card in the server. I'll also have him change the server ethernet cable in between just to be sure. It'll take a bit to get it scheduled and done........

Thanks!

 

[sphere_monk]

The problem has been fixed!

We switched out every piece of hardware we had between a regularly-offending client and the server, all to no avail. Everything we did still pointed to it being a communication error. Packet-sniffing software came up with no packets being lost (although many were being received out-of-order).

We had recently installed a third-party antivirus program (including firewall) on the server and clients. Although the firewall had been shut-off on the server, data appears to have still been passing through the filter that the antivirus hooked onto the ethernet controller. We unchecked the filter on the ethernet controller and all the network access messages disappeared.

Go figure....

Thanks for pointing me in the right direction Galaxiom.

I'm going back to my programming cave.

 

[Galaxiom]

Congratulations. Sorting computers is really about eliminating all the possible causes until one of them does it. The cures are simple but the diagnosis can be a nightmare.

I am reminded of an idiot I used to work with who accused me of fixing computers "by trial and error" and that the problems were usually "just a simple setting". Just like yours. The solution was to untick a box. How hard could that be?

 

[eludlow]

One of my colleagues has recently started getting this error.

However, all other users of the DB (about 10 others) can access no problem, including identical build PCs.

The problematic machine can get on all other files on the server no problem (including other access DBs).

Any idea what to try?

Thanks,
Ed

 

[The_Doc_Man]

The biggest problem with modern anti-virus and heuristic protection schemes is that once they decide you are persona non grata it can be Hell to get back in their good graces. Finding that an anti-virus package has taken a disliking to you can be a real insight into what is going on.

You have to be aware of firewall issues that selective block traffic on oddball ports. You need to be sure that routers with access control lists know to not block your traffic. If a router or firewall gets reset by accident (or replaced after a failure), your configuration needs to be restored. Which is where taking a backup of your firewall rules every so often is better than excellent, it is survival-level.

eludlow, tracing down this problem is a systematic examination of the properties of the users and machines to see what is different. Look for membership in a sub-domain within your primary domain. Remember that one DENY cancels a thousand (or more) ALLOWs. So look at firewalls, routers, and access control entries to see if your "oddball" user and machine are the victims of an obscure DENY. Also, in a formal domain, don't forget that a user has an account and so does the machine! An access control list can be based on a user account OR a machine account, so look for both. Your domain administrator will have to help you in this search, I think. A machine DENY is just as deadly as a user DENY.

There are also possible issues in any startup policies. Again, the domain administrator has to help because that is the person who probably set up the policies.

You have a classic case of the "Hassenpfeffer recipe." It takes a very short time to make hassenpfeffer once you catch a rabbit. But the pacing step is catching the rabbit.

I used to tell my business managers that 95% of all problem fixes took 5 minutes. So when one of them asked me why a problem was taking so long, I said I would stand by my statement to fix it in 5 minutes. When he said, "But it has already been 2 hours" I replied, "Hush, I am still diagnosing the problem. When I have a good diagnosis, I'll fix it in 5 minutes." The guy was dumb enough to ask, "How long will it take to diagnose the problem?" My response? "As long as it takes. Longer, if you are going to ask me silly questions all day." He was dumb, but not THAT dumb, so he left.

Anyway, the trick is to find the difference in characteristics between a working and non-working user. It can be group membership, sub-domain filtering and trust definitions, missing a certificate or digitally signed application, ... all sorts of issues. You'll just have to keep looking until you find the difference.