 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Multiuser / Networking / February 2006Where to house the data MDB
Hi! I'm developing a system for two users. The system itself is split into front end (code MDE) and back end (data MDB) . Both users will have a copy of the front end but only one of them will have a copy of the back end. The computers they will be using have very similar specs except that one of them has a slightly faster processor. Does this follow that I should place the back end on the faster computer? I'd appreciate any advice on this. Thanks in advance! I presume that you dont have a dedicated network server? This is where a backend would normally live... If you even have an old PC lying around you could set up some kind of network drive both PCs can access. however there is no reason that a shared folder on one of the computers with a basic network connection wouldnt work - except that the host PC would have to be switched on any time the other user needs to access the database. I would use the faster machine, not because it would create a faster database connection (thats determined by network data rates), but because it's going to be doing some multi-tasking if the user is doing one thing while the other user is accessing the database. Thanks, BillCo: Yes, for now, I've got two computers on that network. One of them will be operating almost 24hours a day but the transaction volume is much lower (hotel module) than the other computer which will be operating for about 8- 10 hours a day only (restaurant module). So, I guess that's the kind of scenario I''m weighing out: Should I use the faster computer for the hotel module (MDE+MDB) because it has the back end data or should I use it for the restaurant module (MDE) because there are much more transactions being processed there. replicate. put a backend on both machines and put the design master on whichever is turned on the most. the guys who hang out at microsoft.public.access.replication will help you out with this if you are unsure how to go about it... I'm not much of an expert here >replicate. >put a backend on both machines and put the design master on whichever >is turned on the most. >the guys who hang out at microsoft.public.access.replication will help >you out with this if you are unsure how to go about it... I'm not much >of an expert here I respectfully disagree. Replication is not for the faint of heart. And definitely overkill for this environment. It also requires a certain amount of TLC (Tender Loving Care). FWIW I've never used replication myself as I've never quite seen a reason to yet. Tony  SignatureTony 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 respectfully disagree. Replication is not for > the faint of heart. And definitely overkill for this > environment. It also requires a certain amount > of TLC (Tender Loving Care). And, as a very wise colleague said in one of my previous incarnations (as a project management advisor), "You gotta know what you're doin'." The stoutest of hearts won't get your through replication if you don't know what you're doin'. Larry Linson Microsoft Access MVP P.S. Replication is appropriate if you have a base system / systems, and multiple people using the same database "on the road" but unconnected to the source, most of the time. An example is a company with outside sales people who use their notebook computers for booking orders, etc., but can only connect back to the home office at night from their rooms, not from the customers' locations. Larry L. >Yes, for now, I've got two computers on that network. One of them will be >operating almost 24hours a day but the transaction volume is much lower [quoted text clipped - 4 lines] >restaurant module (MDE) because there are much more transactions being >processed there. I'd put the backend on the hotel computer simply because that computer will always be turned on. If you were to put the backend on the restaurant computer you'd never quite know what would happen. Tony SignatureTony 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 would use the Faster computer for the restaurant, and the Slower computer for the hotel. This kind of thing is normally limited by the speed or the bandwidth of the network connection, and with only two computers the network speed and bandwidth are going to be the same at both ends! The hard disk speed can be a factor, but I see that the network is slower than either hard disk. The processor speed can be a factor when it influences network speed, but since the Hotel computer is lightly loaded, the processor probably won't limit network speed most of the time. Memory size can be a factor if the Hotel computer is trying to do two things at once, but that would probably have more effect on the useability of the Hotel computer, because the Restaurant computer will be limited by network speed and bandwidth anyway. And if it is a problem you should just buy some more memory. (david) > Thanks, BillCo: > [quoted text clipped - 6 lines] > restaurant module (MDE) because there are much more transactions being > processed there. thanks david! there are actually more computers on the network but for the sake of simplicity, i only mentioned the two. anyways, the rest of the computers don't really interact with the hotel-resto computers, except for the accounting computer which accesses the data MDB for reports and this is done only once a day. ok, i'll try out your suggestion and see what happens. thanks again! |
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.