Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Security / July 2004

Tip: Looking for answers? Try searching our database.

WinXP-Acc2003 slow performance for certain security levels

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Ethan - 12 Jul 2004 22:38 GMT
Hello,
I am seeing different performance for users based on their security level when using Access 2003 on WinXP.  

I have two security levels--HI and LOW.  When a user is logged in as a HI user, performance is normal.  When the user is logged in as a LOW user, the cursor periodically freezes while while the user continues to type.  Eventually (3-4 sec.) the cursor frees up and displays all typed characters.  As you can imagine, this isn't critical but annoying.  

Oddly, the HI and LOW users have the same level of permissions for the sections of the application where I am testing.  Most obvious in longer text and memo fields.

Now some background.  All db files are in Access 2000 format (FE, BE, Wrkgrp).  The OS is WinXP and the server is Win2k.  Jet, Office and Windows are all up to date with service packs.  Permissions are correct at the network level--full rights.  
 
My first test was to converted all the databases to 2003 format.  No luck.  I also sent over another copy of the database and saw the same performance.  I tried other workstations same problem.  I brought the FE-BE local and the performance was improved, but I "think" I still saw a slight delay sometimes.  I also created new users at each security level.  Still no luck.        
   
I tried to duplicate error on my network (with same OS and client setup), but was not able to.  I would love to blame this on their network, virus scan software or firewall, but that doesn't make sense because the High user does not experience the slow down--only the LO user.

Any thoughts would be greatly appreciated,
Ethan
Albert D. Kallal - 15 Jul 2004 01:53 GMT
Hum, that is strange.

Are we to assume that you install a mde on each workstation?

Can we assume that if you reverse the sequence of testing (and log ons ) you
still get a slow down?

Does the number of users connected to the back end matter?

I would certainly make sure each workstation gets their copy of the FE (you
need to do this anyway). I would also give each user  mde, turn off track
autoname correct, and also keep a persistent connection open. I would also
turn off any sub datasheet display stuff also

The above fixes 99% of these types of problems. If the above don't
work..then check out the following list of got ya's:

http://www.granite.ab.ca/access/performancefaq.htm

Signature

Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn

Ethan - 15 Jul 2004 15:04 GMT
Albert,

Thanks for the reply.

To answer your question, for testing purposes, I am the
only one in the database.  However, we have seen the
problem with multiple users in the database.  There is no
change in performance as far as order of log in.

I am aware of the other suggestions and of the performance
FAQ on Tony's site.  I have implemented most of the
suggestions found here and on the sites.  The frustrating
thing is that performance in the envrionment in question
is great--except for this one issue!!  Opening forms,
querying data, etc. is all very fast.  It would make sense
to me that if any of these issues were causing my periodic
slow down, it would happen similarly for all users and
groups and show itself in the normal places.  I have seen
performance problems before, but never isolated to a
single MS Access permission group.

I am somewhat at a loss.  My current plan is to recreate
the security file from scratch.

Thanks again,
Ethan  

>-----Original Message-----
>Hum, that is strange.
[quoted text clipped - 15 lines]
>
>http://www.granite.ab.ca/access/performancefaq.htm
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.