 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Multiuser / Networking / December 2004How Access tranfers data across the LAN
I have several questions concerning how Access 97 transfers data across the LAN. Our database has the following configuration. FE is located on the user’s pc. The BE is located on the LAN. It is my understanding that Access transfers entire tables included in a query across the LAN to the client pc before it can be processed. Is this correct? When data is updated, are the entire tables transferred back across the network or just the records being updated? Our office LAN is 10 Mbps. What is the bandwidth of typical office LANs? I’ve read where fast Ethernet LANs are at 100 Mbps. Are these common? Some of the users in our company are running VM Ware on their computers which assigns multiple IP addresses to their computers. Are there any known issues with running VM Ware and Access 97? Any suggestions as to where I can get additional technical information on any of the above topics? Thank you very much for your help! Weste > It is my understanding that Access > transfers entire tables included in a > query across the LAN to the client > pc before it can be processed. Is > this correct? No, this is not correct. It is a commonly-held misconception based on the fact that all data extraction and manipulation of a Jet database IS performed on the user's machine. Only as much information as is needed to obtain the requested data will be transferred. The shared backend is used just as if if were a file on the local hard drive. If the specific record desired can be determined by only retrieving indexes, and then the single record, that is all that will be done. That is what would be done on a local hard drive, too -- read the index until you identify the specific record needed, then read that record directly. Poor design and implementation, however, can force what you describe. That is, if you don't use indexes appropriate to your retrieval, it may, indeed, be necessary to read the entire table. > When data is updated, are the entire > tables transferred back across the > network or just the records being updated? More likely, just the updated index entries and the updated record. But, see above. > Our office LAN is 10 Mbps. What is the > bandwidth of typical office LANs? I've > read where fast Ethernet LANs are at 100 > Mbps. Are these common? The slowest LANs that I have encountered in recent years were "Ethernet 10/100"... that is, capable of 100 MBPS, but compatible with, and reverting to, 10 MBPS if the attached hardware has that limit. A few years earlier, 10 MBPS was not uncommon; even earlier LANs ran at 4MBPS or slower. A number of years ago, I ran a split Access 2.0 database on a 4 MBPS LAN, and that was detectably slow; I ran a split Access 97 database on a 10 MBPS LAN, and that was "adequate" but obviously slower than running the same database on a 100 MBPS LAN. Performance will vary depending on what else you are running on the LAN and how much data it transfers, as well as with how much data you are transferring. The latest is "gigabit Ethernet", rated at 1000 MBPS -- I've seen some new desktop machines that come standard with 10/100/1000 MBPS. I haven't run a split database in a gigabit environment, but I'd guess that it is difficult to determine whether it is running across the superfast LAN or from the local harddrive, if you are sitting in front of the monitor. > Some of the users in our company > are running VM Ware on their computers > which assigns multiple IP addresses to >their computers. Are there any known > issues with running VM Ware and Access 97? I'm only "barely introduced" to VM Ware, so someone else will have to address this. > Any suggestions as to where I can > get additional technical information on > any of the above topics? There are so many factors in performance that it is impossible to predict how they will interact. There's an introductory presentation on Access in a Multiuser Environment that I did for my user group that you can download from http://appdevissues.tripod.com. It will identify topics that I thought worthwhile to discuss, and a bit more. The best collection of detailed information and links on the subject of Access in the multiuser environment is at MVP Tony Toews' site, http://www.granite.ab.ca/accsmstr.htm. Larry Linson Microsoft Access MVP Thank you very much Larry for the great responses. > > It is my understanding that Access > > transfers entire tables included in a [quoted text clipped - 68 lines] > Larry Linson > Microsoft Access MVP >If the specific record desired can be determined by only >retrieving indexes, and then the single record, that is all that will be >done. Actually data is fetched in pages and not records. >That is what would be done on a local hard drive, too -- read the >index until you identify the specific record needed, then read that record >directly. And, of course, the index is not read sequentially but in a binary tree so 10 reads should be sufficient to locate a specific record in several million >I haven't run a split database in a gigabit environment, but I'd guess >that it is difficult to determine whether it is running across the superfast >LAN or from the local harddrive, if you are sitting in front of the monitor. I wonder though how much of the slowdown would simply be in the processing in the network card and waiting for network collisions to resolve themselves and such. 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 > I wonder though how much of the slowdown would simply be in the > processing in the network card and waiting for network collisions to > resolve themselves and such. Some computers have on-board Ethernet ports which load the processor, and I have on record an observation about a split database that was running much slower on a Celeron than on a Pentium. But my personally experience was with a system where local copies of all the static tables were indistinguishable from a 100Mb network. > >If the specific record desired can be determined by only > >retrieving indexes, and then the single record, that is all that will be [quoted text clipped - 25 lines] > Microsoft Access Links, Hints, Tips & Accounting Systems at > http://www.granite.ab.ca/accsmstr.htm >> I wonder though how much of the slowdown would simply be in the >> processing in the network card and waiting for network collisions to >> resolve themselves and such. > >Some computers have on-board Ethernet ports which load the >processor, I'm not at all sure that having an on-board Ethernet would be any faster than a card in a PCI card slot. It might be but I don't know that. It also might not be significant in terms processing data. >and I have on record an observation about a split >database that was running much slower on a Celeron than on a >Pentium. Hmm, that's possible but I'd suspect other factors in a system with a Celeron such as small CPU/L1 cache or overall cheapness of system including network card. >But my personally experience was with a system where local >copies of all the static tables were indistinguishable >from a 100Mb network. <shrug> Then I suspect we'll agree to disagree. I certainly see a difference when doing some testing on my home network especially when relinking tables. Where the time taken is particularly noticeable. 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 > >But my personally experience was with a system where local > >copies of all the static tables were indistinguishable [quoted text clipped - 3 lines] > difference when doing some testing on my home network especially when > relinking tables. Where the time taken is particularly noticeable. Mine was a statically linked A97 application at a single site. Because it was running slowly, I went through the exercise of creating local copies of all the semi-static data tables, and a startup process which compared an update record between a local and a network copy for each 'replicated' table. The comparison query added noticeably to the start-up time, but it wasn't a major issue, because all else being equal, the application was in use all day. However, at just about the time I finished, I also noticed that the little '100' light was not lit on the workstation network card. On investigation, we were told that the network switch had never been re-set to '100': lacking any direct request, the network people had left it at '10', in case there was any hardware which did not support the higher speed. When they re-set the switch, we got the same apparent speed from the old application as from the new application. Any test like that is going to depend on the hardware and the specific application: noticeably, hard drives have continued to increase in speed since then, and memory management is probably slightly different with Win XP than it was with Win 2000. We relinked the static data tables, to avoid the extra startup delay (david) > >> I wonder though how much of the slowdown would simply be in the > >> processing in the network card and waiting for network collisions to [quoted text clipped - 30 lines] > Microsoft Access Links, Hints, Tips & Accounting Systems at > http://www.granite.ab.ca/accsmstr.htm > Actually data is fetched in pages and not records. Thanks, Tony. My brain must have been taking a mini-vacation. <SIGH ... Physical Records rather than Logical Records. That's what you meant anyway, right? :~) (david) > > Actually data is fetched in pages and not records. > > Thanks, Tony. My brain must have been taking a mini-vacation. <SIGH > ... Physical Records rather than > Logical Records. That's > what you meant anyway, right? :~) Hmm. Must have been so. Haven't used those (perfectly accurate) terms since my previous incarnations as a mainframer and minicomputer programmer, I think. <GRIN |
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.