 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Multiuser / Networking / September 2004Network Question - Access
May not be the proper newsgroup, but maybe you can direct me! Situation: Have fairly extensive Access 97 database. Back end tables located on very busy office network, individual identical front ends located on individual PC's. Front ends are linked to back end tables via generic path \\xxx\yyy\zzz. At times application speed will slow to a crawl. Have determined that if front ends on adjacent PC's are set up with the table links different, the apps speed will be different. Example: PC#1 where front end linked to back end tables via the generic network path \\xxx\yyy\zzz is always slower than PC#2 where front end is linked via specific mapped network drive pointing directly at the zzz folder. Anybody else have similar problem? -- Allen Hardy III For you are a mist appearing for a little while and then disappearing. James 4:14 >May not be the proper newsgroup, but maybe you can direct me! > [quoted text clipped - 12 lines] > >Anybody else have similar problem? No, this is the first time I can recall anyone ever posting this particular problem. And it's a very interesting posting. Are there two different LDBs created on the server directory when a file is opened in this fashion? The obvious answer is to not do that. <smile> If the users are given the option of relinking the tables ensure they choose the network path by verifying that the first two characters of the path are back slashes. Thanks for posting. Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips & Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Thanks for reply! Several other items: 1) When accessed by several users, only one ldb is open for the back end tables (mdb's) that reside in the network directory. 2) Individual front ends on each users PC of course will have their own ldb when user has app open, however, it is on their hard drive. 3) The front ends are actually mde's that users cannot relink. The entire application uses Access security and the front ends have timers which prevent users from leaving application open for extended periods of time (there are known problems with access databases when # of users approaches 15-20). 4) Another example of problem (keep in mind - back end tables are a the sub-directory zzz on the server): When a user signs on network they will normally have a default mapping to the server which can be seen in their tree as E(drive): yyy (directory) on xxx (server). I now map a second drive F, which reads in their tree as F(drive): zzz(sub-directory) of yyy(directory) on xxx(server). Now we put identical front ends on users PC, except one front is linked to the tables as \\xxx\yyy\zzz. The second front end is linked via F:\xxx\yyy\zzz. You can open both front ends at same time on the users PC and notice that the second one will respond faster!!! I'm 99.99% sure that the slow response is due to the network situation - I've accused our IT group in jest many times of developing these wonderful company apps that will speed up everyone's job and then the network group turns around and give users a dial-up connection!!!! Again, I quess I'm not looking for any solutions - maybe just a confirmation of my suspicions and a little sympathy. It's amazing how we, as users, come to see the difference between an instantaneous and a 4 second delay response as being an eternity! -- Allen Hardy III For you are a mist appearing for a little while and then disappearing. James 4:14 > >May not be the proper newsgroup, but maybe you can direct me! > > [quoted text clipped - 32 lines] > Microsoft Access Links, Hints, Tips & Accounting Systems at > http://www.granite.ab.ca/accsmstr.htm > Thanks for reply! > Several other items: > 1) When accessed by several users, only one ldb is open for the back end > tables (mdb's) that reside in the network directory. That is normal and correct. The ldb file is how the ms-access can resolve conflicts, since there is no software running on the server side to do this!! > 2) Individual front ends on each users PC of course will have their own > ldb > when user has app open, however, it is on their hard drive. Excellent, the above is a recommend setup. > When a user signs on network they will normally have a default mapping > to the server which can be seen in their tree as E(drive): yyy > (directory) > on xxx (server). Now, the above is a problem waiting to happen. You should not care, or even worry, or even bother with drive mapping. Drive mapping can change so easily, and the result is more support calls. You should always simply use a full path name to the files, just forget about the drive mapping. This is call UNC path names: \\yourServerName\dirname\MyData.mdb > and notice that the second one will respond faster!!! In fact, the #1 thing you can do to improve response time is that when your application opens, just open a form, or in code open a recordset to ANY table in the back end. So, the trick here is to force/keep the connection open at all times. Do this will get rid of those delays you talk about.. Also, when you create the link to the back end file, simply browse via network neighbor (my network), and then to the server, and then to the directory and then to the file name. that way. The result will be a linked UNC path name, and you will completely ignore the drive mapping, and eliminate one weak spot here.  SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.attcanada.net/~kallal.msn > > When a user signs on network they will normally have a default mapping > > to the server which can be seen in their tree as E(drive): yyy [quoted text clipped - 8 lines] > > \\yourServerName\dirname\MyData.mdb I have a small app on my home network using my desktop as a "server" with a mapped drive, and other pc's that link to it. Since it uses full path calls to retrieve .jpgs, I need to have all paths from all pc's the same. The problem is that even with a persistent table opened, having the db back end opened on one pc often blocks the others from opening. Is there a restriction how the table should be opened (read only?)? I suspect that my link-check routine is locking up when it gets to the persistent table, but I haven't been able to pin it down to this. I've had other users set up on full networks who have also had problems with this, but they are also using mapped drives. In a peer-to-peer network, there is a limit on the number of open connections. That may be what you have encountered. I believe it is 10 with Windows XP, but fewer on earlier Windows versions. Except for very tiny user audiences, it is necessary that the back-end be in a shared disk on a domain server to which the users are logged in. Larry Linson Microsoft Access MVP > > > When a user signs on network they will normally have a default mapping > > > to the server which can be seen in their tree as E(drive): yyy [quoted text clipped - 19 lines] > networks who have also had problems with this, but they are also using mapped > drives. > No, this is the first time I can recall anyone ever posting this :~) grin :~) Have a look at Tony's Performance FAQ at http://www.granite.ab.ca/accsmstr.htm :~) more smiles :~) The user has just described a situation where the data directory is mapped as a root flooder, as compared to a mapping that requires several levels of folders: "Alternatively I'd suggest having the network people setup a share right on the directory of your BE for your use. Instead of using \\Server\Dir1\Subdir2\Subdir3\subdir4\subdir5\backend.mdb you'd use \\server\Sharesubdir5. :~) (david) > No, this is the first time I can recall anyone ever posting this > Microsoft Access Links, Hints, Tips & Accounting Systems at > http://www.granite.ab.ca/accsmstr.htm |
Reply to this Message |
 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.