We have a software product that has been running successfully for a customer for several years. Suddenly and literally overnight, any client stations at any location exhibits problems when accessing its mdb file. Each location has its own subfolder containing its own mdb file. (\\Hostname\Shared-folder\ Location\mdb-file) Whenever a client program attempts to open the mdb file to perform a read or write, there is a long delay - in fact, during this delay, attempts to use Explorer or the command line prompt to view the mdb file's folder similarly locks up. Status in the Task Manager's Applications tab shows "not responding". A typical delay is around two minutes. Using the FileMon utility, we can see the delay occurs immediately after a file open attempt. This behaviour is not limited to just our application, but also when attempting to open the mdb file in Access or the LDBView utility. (However, copying to a local drive and using it there exhibited no problem.) We thought that maybe their antivirus was causing a problem (perhaps a delay caused by scanning for scripts), but customer insists the AV configured for no active scanning when trying to open a file. Interestingly, opening text files of multi-MB size in the same folder does not have the same delay problem. We also investigated ODBC settings for an incorrect PageTimeout value but this was a dead end. Any ideas?
It's not clear exactly what your architecture is, but is appears that you have more than one database exhibiting this behavior? If that's the case, then do all of those databases connect to the SAME database? If so, then I'd suspect corruption in that common database.
Otherwise, look for anything that's common among the problem databases - do they all share the same network segment, for example, or do they all connect through the same switch/router ... in most cases, sudden and widespread issues like this are almost always caused by something common among the databases. We've had AV issues similar to what you're reporting, but typically this doesn't affect the opening of the database.
Thanks LSM. A little more info: yes, more than one database, each location has its own mdb file, but there is no master or common database connected to these. The folders exist on a SAN, so maybe it is a networking issue. Moving the mdb files to other folders on the SAN produced the same problems. Customer's IT will be running Ethereal to capture some info for us. Apparently there have been no problems running other applications on the SAN.
James this is going to be a long one but maybe you will find some help in what i'm dealling with. I'm usually the person asking question not answering them lol. But in this case i was going to ask a similar question. I'm experiencing nearly the same thing you are with just "one" of our clients. In my case the data base program i support has been sold to over 200 clients, each client has anywhere between 5 to 30 concurrent connections at any given time. It opperates off of a simple network share and for the past 5 years i have been the point of conact for any problem outside of programming issues. So i have seen my share of performance related issues. LSM made some good valid remarks. What i have discovered with the client i am having problems with is that the problem 1st occured this monday but it so happens they had a power outage in the building that houses the server the week before while everyone was on spring break and the generator did not kick in. Fast forward a bit so this monday when they come in to do some work, everyone complains that their locking up or performance is at a crawl. We restored the database to a point before the power failure and still have the same problem. put the data on another machine still has the same problem. my 1st suggestion was for them to restart the switches but they refuse to because of concerns it could cause other problems, voip and other network services( gee I'm wondering now). So i suggest lets make a controlled environment. I have them segment off a server and up to 9 workstation and all works well. I'm familiar with terminal service so that in environments with low bandwidth I roll out the app in a thin client solution. So at this point i have all the users in the business running the data with no problems as long as they don't run it over a fat client. with this result they are planning on resetting the switch saturday ( wish me luck) Now for you. other things that i might concider: -Can you run the Database client right on the server? if yes how does it perform? -Over a network share how many users can access the data before it gives you a problems?
performing a controlled connection test might be an option. puting on a dedicated switchmay eliminate other network related issues.
Most important though is what new thing has been introduced to the environment. alarm systems. video, antivirus software, just things to concider,,,,,,,,,,,,,,,,,,,,,,,,,,good luck Rob
