 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Multiuser / Networking / December 2004Shared FE database question.
What's the difference between executing a read-only copy of a shared FE, and having copies on each client machine? ( besides some "performance" issue. A 100 mb/sec LAN is pretty good at delivering data) > What's the difference between executing a read-only copy of a shared FE, and > having copies on each client machine? ( besides some "performance" issue. > A 100 mb/sec LAN is pretty good at delivering data) Read-only applies to data; front end applies to Access objects. Access will be writing/saving internally in the front end. Having multiple users logged in to the same front end significantly increases your chances for corruption. And, a 100 megabit LAN is, indeed, pretty good at delivering data. But, if you are using a front-end that is stored on another machine, it will also have to deliver every object in that front end that you load, to each user who uses it. Do you foresee some problem with each user having a copy of the front end and linking to tables on a shared folder on the server? If it is a matter of keeping those FEs updated, see MVP Tony Toew's site http://www.granite.ab.ca/accsmstr.htm for his Front-End updater, or visit http://accdevel.tripod.com to read how I have handled it in the past. Larry Linson Microsoft Access MVP >> What's the difference between executing a read-only copy of a shared FE, > and [quoted text clipped - 7 lines] > users logged in to the same front end significantly increases your chances > for corruption. I was not aware that an Access FE would be writing/saving data to itself, rather than to the linked table database ( BE ) . What would be the nature of these writes and saves. ? Wouldn't the read-only status of the FE prevent this ? Or doesn't windows read-only really work. > And, a 100 megabit LAN is, indeed, pretty good at delivering data. But, if > you are using a front-end that is stored on another machine, it will also > have to deliver every object in that front end that you load, to each user > who uses it. True. But don't fequently used objects end up in paged memory on the FE instance machine ? We've been operating in this environment for 7 years, and forms with query data seem to have response times of 100-200 ms. BTW, Thanks Larry, for your serious and thoughtful responses. I'm just trying to understand Access database architecture, and what has changed in the trasition from Access 3-97 to Access 2000. I may be trying to cary over too much of my background in mainframe DB2 and SQL/DS, VM, MVS, TSO, and VS/APL. of keeping those FEs updated, see MVP Tony Toew's site > http://www.granite.ab.ca/accsmstr.htm for his Front-End updater, or visit > http://accdevel.tripod.com to read how I have handled it in the past. > > Larry Linson > Microsoft Access MVP > > Access will be writing/saving internally > > in the front end. Having multiple users [quoted text clipped - 6 lines] > to the linked table database ( BE ). What > would be the nature of these writes and saves? Access' internal working storage... that is not written to tables in the linked database. Like every other Windows program, it obtains memory and writes its own files (not tables) that it uses in doing its work. > Wouldn't the read-only status of the FE > prevent this ? Or doesn't windows read-only > really work. No, I don't think you can successfully specify an Access front-end to be read-only and have it work. > > And, a 100 megabit LAN is, indeed, > > pretty good at delivering data. But, if > > you are using a front-end that is stored > > on another machine, it will also have to > > deliver every object in that front end > > that you load, to each user who uses it. > True. But don't fequently used objects > end up in paged memory on the FE > instance machine? Nothing can be cached in that manner until it is retrieved. And, I am not knowledgeable about the performance improvements due to memory caching. I do know that a 100 MBPS network is a poor substitute for a local disk drive. > We've been operating in this environment > for 7 years, and forms with query data > seem to have response times of 100-200 ms. Response times of 100-200 NANOseconds? I wouldn't even know how to begin measuring that. I haven't had any experience, nor heard any reports, on performance over the new gigabit networks, but one of those would be a much better substitute for a local hard drive. In any case, the vast preponderance of opinion is that each user should have their own copy of the front end. > BTW, Thanks Larry, for your serious > and thoughtful responses. You are welcome. > I may be trying to cary over too > much of my background in > mainframe DB2 and SQL/DS, > VM, MVS, TSO, and VS/APL. There are certainly very major differences in mainframes and in networked PCs. In a previous incarnation, I, too, was a mainframer and minicomputer programmer. Larry Linson Microsoft Access MVP > > > Access will be writing/saving internally > > > in the front end. Having multiple users [quoted text clipped - 10 lines] > linked database. Like every other Windows program, it obtains memory and > writes its own files (not tables) that it uses in doing its work. Well, Access isn't suposed to be every other Windows program ! It's suposed to be a multi-user application. If it writes its own files, it should keep track of the user ( or better yet the transaction) so it doesn't corrupt them. > > Wouldn't the read-only status of the FE > > prevent this ? Or doesn't windows read-only > > really work. > > No, I don't think you can successfully specify an Access front-end to be > read-only and have it work. You can. And, it works( in VERY limited testing). You can open, update and insert into linked tables. > > > And, a 100 megabit LAN is, indeed, > > > pretty good at delivering data. But, if [quoted text clipped - 11 lines] > do > know that a 100 MBPS network is a poor substitute for a local disk drive. It's definately slower. But poor or good substitute depends on your requirements. I happen to think distributing code all over the user base is a poor substitute for having a shared code store. > > We've been operating in this environment > > for 7 years, and forms with query data > > seem to have response times of 100-200 ms. > > Response times of 100-200 NANOseconds? I wouldn't even know how to begin > measuring that. "ms" is a milisecond, not a nonosecond. 200 ms is .2 seconds. > I haven't had any experience, nor heard any reports, on performance over > the [quoted text clipped - 5 lines] > have > their own copy of the front end. I'm aware of the prevalence of the "opinion". I'm questioning it. > > BTW, Thanks Larry, for your serious > > and thoughtful responses. [quoted text clipped - 9 lines] > PCs. In a previous incarnation, I, too, was a mainframer and minicomputer > programmer. And I'll bet you'd go ballistic if someone corrupted a multi-user application by creating a scratchpad work area that mixed up the data from multiple users. > Larry Linson > Microsoft Access MVP Ed -- I have had no reason to question that having multiple users logged in to the same front-end or monolithic database does increase the chances of corruption. I have seen and read of too many instances to doubt it. There's not being overly happy with the way some software is desinged and implemented; there's also being so unhappy with it that you feel compelled to do the equivalent of spitting into the wind. That, at least, I have learned in my years (since 1958) in the computer business. And, I try to limit myself to the first and go ahead and work with the software rather than against it. I have been splitting front-end and back-end since the days of Access 2.0, but I acknowlege that Access 2.0 seemed to be a lot less sensitive to having multiple users logged in to the same front-end. I've had no troubles (also since Access 2.0 was a stripling) with determining when there was a need and informing the user that they could or must download a new copy of the front-end. I believe you'll find a writeup at http://accdevel.tripod.com. MVP Tony Toews took a different approach and created an Auto FE Updater, which you can find at his site, http://www.granite.ab.ca/accsmstr.htm. Those approaches ought to take some of the pain out of distributing front ends to multiple users. Good luck with what you are trying to do. Larry Linson Microsoft Access MVP >I was not aware that an Access FE would be writing/saving data to itself, >rather than to the linked table database ( BE ) . What would be the nature >of these writes and saves. ? One source is query plans. Another would be form filters and such. I'm sure there are other things of which we're unaware. >Wouldn't >the read-only status of the FE prevent this ? Or doesn't windows read-only >really work. I recall reading one or two postings a while back stating that keeping the FE as read only did work for him. Presumably though he wasn't relinking tables or adding temporary linked tables as required and such. >> And, a 100 megabit LAN is, indeed, pretty good at delivering data. But, if >> you are using a front-end that is stored on another machine, it will also [quoted text clipped - 3 lines] >True. But don't fequently used objects end up in paged memory on the FE >instance machine ? One of my clients is running an terminal server system and placing the users FE on the file server. It's working for them but we've never tested the difference in response times doing this. I suspect it's slightly sluggish but the IT admins didn't want me to even test this scenario. 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 |
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.