3bd9b49a   
   XPost: microsoft.public.sqlserver.server, comp.databases.ms-access,   
   microsoft.public.access   
   From: johnvonc@earthlink.net   
      
   This may or may not be relevant.  A client of mine recently started   
   having trouble under similar circumstances. It actually turned into two   
   distinct problems. First, they had switched primary DNS servers as part   
   of a server upgrade, which succeded in "confusing" the entire network.   
   Once that was fixed, there were still problems. The network admin   
   traced it to an intern who was hooking up their laptop to the network,   
   inside the firewall. The laptop had a full version of Windows Server   
   2003 on it with DNS, RAS, SQL Server 2008, you name it! It completely   
   screwed up access to the database, unless you ran the front-end from   
   the server. Symptoms were very similar to yours...   
      
   Good luck!   
      
   John   
      
   Edward submitted this idea :   
   > ACCESS 2003 Front End - SQL Server 2000 database   
   >   
   > Last week my clients reported problems with their application which   
   > has been running fine.  They said that it had been very, very slow,   
   > and that forms, when loaded, displayed #Error and #Name in fields.   
   >   
   > The application normally runs on a terminal server (don't ask - not my   
   > idea!) and we found that one of the disks was broken, and so we moved   
   > the application onto a user's client machine and reconnected to the   
   > database.   
   >   
   > Same problem - very slow, and constant ODBC error messages (mostly   
   > "Connection to SQL Server Server01 failed")  My belief is that these   
   > are caused by timeouts.   
   >   
   > So I backed up the database and copied it and the application onto our   
   > network.  It works absolutely fine with no latency.   
   >   
   > Our network admin doesn't think that there's a network problem per se   
   > because file transfers seem to be ok.  The memory usage on the SQL   
   > Server box is quite high (2.5 Gb) but we don't think that's the   
   > problem.  I created a dummy query that I ran on their SQL Server to   
   > see if there was some performance issue, but the query (a reasonably   
   > large INSERT) took 983ms on their server, while it took 1,330ms on   
   > ours (ours isn't a very high spec. machine!)   
   >   
   > We aren't aware of any other issues such as recent updates or new   
   > programs.  We've turned virus checking off, but that hasn't changed   
   > recently anyway.  The crunch question is why, connecting an identical   
   > front end to an identical back end, it fails on their network and it   
   > doesn't on ours.   
   >   
   > I am in the process of installing Access on their SQL Server box, to   
   > keep it entirely local.  I've also arranged for our network engineer   
   > to install a new hard disk on the terminal server and, at that time,   
   > I've given him a laptop with the application installed that I've   
   > tested here connecting to our installation of SQL Server (runs fine   
   > with no errors and no latency), which he will connect to their network   
   > so that I can test that.   
   >   
   > But does anyone have any other thoughts that might be of help?   
   >   
   > Many thanks   
   >   
   > Edward   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)