Results 1 to 15 of 15
  1. #1
    Join Date
    Jul 2002
    Posts
    1

    Exclamation Unanswered: slow network performance

    We have an Access application that was converted from 97 to 2002. The front-end resided on 5 computers running Win98SE and the back-end resided on a computer also running Win98SE. Everything has ran smoothly with the Access application. Recently, we replaced two computers with PCs running Windows XP Professional. We placed the back-end on one of the XPs.

    However, the Access application is slow to process data. The application has no problem displaying data when forms are opened, but is slow to execute code that processes data (e.g., DMin statement, openrecordset statements, etc.) when more than one user is in the application. If we place the back-end back onto one of the Win98 PCs, the application works with no problems. Problems only occur if we place the back-end on a XP PC. We would really like to place the back-end onto one of the new XP PCs though. I even brought in a W2K PC to see if I get the same problems and the same thing occurred. Right now, we are keeping the back-end on one of the Win98 PCs until we get this problem resolved.

    The PCs are connected to one another through a LinkSys 8 port switch and are using TCP/IP protocol. The XP computer also serves as a ICS host. (Note, the Win98 computer that was replaced also served as a ICS host).

    Any ideas? I would appreciate any help! This problem has been really frustrating.

  2. #2
    Join Date
    Feb 2002
    Posts
    403
    I have a suspicion the RAM isn't large enough. Access 2002 requires 64 megs and Windows XP requires 64 megs. I am not an expert on Networks but I think Access 2002 requires 64 meg for each user so if you have 4 users and XP on the same machine I think you need 320 meg just for the Access Application. If you are also running other applications you could need more.

    For the exercise if you speak nicely to your computer supplier they may be able to fit double the RAM and try it.

  3. #3
    Join Date
    Aug 2002
    Posts
    4

    Access Slow Backend

    I have the same problem with our DB which was developed using Access 2000. I suspect that if you install XP on a FAT32 partition and install the backend on this machine it will work OK. Memory shortage is not the problem here as I have 512MB on the machine holding the backend.

  4. #4
    Join Date
    Aug 2002
    Location
    Newport News, VA
    Posts
    8

    Recompile and reindex

    By default, Access databases are in an uncompiled state when they are upgraded. Go to module view and debug the whole thing. Then save it.

    I also recommend verifying your indexing. This can have a tremendous impact on data searches.

    Hope this helps.

  5. #5
    Join Date
    Aug 2002
    Posts
    4
    I have rebuilt and reindexed the front end and backend but this makes no difference. The systems workd fine as long as the back end is on a Win 98 / ME OS. If you move it to a 2000 / XP OS the database performs just as it did before as long as only one person is using it. As soon as a second person links to the backend performance slows down 100 fold, with Forms and queries taking an excessively long time to run.

    A second problem I have just discovered is that if you use VB to compact and repair the backend on XP it makes to backend accessable only to to user who initiated the compact process via their frontend! Whilst other users can see the backend they can no longer open it. In fact XP says its no there!!

    I have come to the conclusion that any version of Access later than 97 is not suitable for use as basis for multiuser applications on an NT platform.

  6. #6
    Join Date
    Aug 2002
    Location
    Newport News, VA
    Posts
    8

    Last ditch effort

    The last possible suggestion I can make is to go into "Options" then "Advanced" and adjust the record locking.

  7. #7
    Join Date
    Aug 2002
    Posts
    23
    I have been experiencing a similar problem. A multiuser app I wrote in Access 2k used NT 4 as a server. User machines were a mix of NT and 2000 pro. Response times were never a problem.

    As soon as the server was switched to 2000 pro, the response time went up by magnitudes.

    Rick

  8. #8
    Join Date
    Sep 2002
    Location
    Coventry, Warwickshire, UK
    Posts
    74
    I too am experiencing poor performance with an Access 2000 app using NT4 as the server and NT on all workstations. As more people log into the app the logon time gradually goes from about 18 secs for the first User out to 5 - 7 minutes for other Users depending on the time of day and therefore how heavy the network is loaded.

    I have also discovered that building the toolbar using the Office 9.0 Object Library takes most of that time. This may be due to the way that Access 2000 has been installed on our servers by the IS department, but I can't see why.
    Roger Hampson
    XI - ecs (UK) Ltd

  9. #9
    Join Date
    Aug 2002
    Posts
    23
    Another issue I have seen since we switched from NT to 2000 pro.

    I prefer to keep all of my work on the server. On the NT system, I never had a problem creating a mde file on the server. In WIN2k, I have NEVER been successful. I always have to copy the mdb file to a local drive, create the mde, and then copy the mde back to the server.

    Access 2K crashes every time I have tried this, from any workstation I have tried it on.

  10. #10
    Join Date
    Jul 2002
    Location
    Australia
    Posts
    147
    I've never had a problem with multiple Win2K Pro / Win98 front-ends with back-end on Win2K Server.
    There have been many posts made throughout the world.
    This was one of them.

  11. #11
    Join Date
    Sep 2002
    Posts
    1
    It may actually be a networking/XP related problem. Check this out:

    http://support.microsoft.com/default...;en-us;Q315237

  12. #12
    Join Date
    Jul 2002
    Posts
    55
    Woo! Stealth bump

    There are issues with opportunistic locking of files on Windows NT and 2000. When more than one user on a workstation attempts to open a file, NT/2K starts throwing oplocks around like there's no tomorrow. I've seen this have a huge impact on performance in file/server applications.

    Try turning off oplocks on the server and see if that helps. It's a registry hack: you should be able to find it by searching MSDN online for "opportunistic lock".

    Mull.

  13. #13
    Join Date
    Sep 2002
    Location
    Coventry, Warwickshire, UK
    Posts
    74
    Would this give problems with the .ldb file when two Users are trying to log in simultaneously. We are getting an error message saying the first User is locking files when the second User tries to log in. At the stage it happens, it can only be the .ldb file.
    Roger Hampson
    XI - ecs (UK) Ltd

  14. #14
    Join Date
    Jul 2002
    Location
    Australia
    Posts
    147
    Also check your NTFS and group permissions on the folder.

    Cheers,
    Andrew
    There have been many posts made throughout the world.
    This was one of them.

  15. #15
    Join Date
    Jan 2004
    Posts
    5

    Access 2000 slows considerably with multiple users

    This is going to sound strange but I may have a work around.

    At my work we run:
    Access 2000 on Windows 2000 clients with the frontend on a local drive and the backend on an NT4-based Back Office 4.5 Server.

    I've seen access slow down when more than one user is on a database across a network. This happened to two databases, designed by two completely different people, at our organization.

    For both databases, the first user logged into the front end and everything was fast. Then the second user opened the front end and it takes 10 or 20 times as long to get to the form (60 to 80 seconds depending on the database in question). I tested a theory and found that the same thing occurred if one user was simply in the back end (without any tables open) and another user opened the front end.

    For the first database, the problem seemed to be caused by the "Compact and Repair Database" utility. We solved the issue this way: after you compact and repair make a slight change to one of the forms and then save the front end. Distribute this slightly uncompacted database to your users and you can have many users on the database without noticing any major speed difference.

    The second database was a little tricky (it would run slow for a second user regardless of whether we had compacted and repaired or not). Upon opening, the database did detach and reattach all of the tables from the back end. We disabled the code to do this, made a slight change to one of the forms and saved the database. After distributing this version, the problem was solved.

    I don't have a clue why this should happen, but it does. The Compact and Repair Utility must have something in common with the code we used to detach and reattach the tables. I can't find much documentation on what compact and repair does exactly, just a whole bunch of people that say you should do it because it's the best thing since sliced bread. If someone can attach a Why to my How I would love to hear it.

    Let me know if this fixed the problem.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •