Marc, If it was properly designed I don't believe it would happen. The only crash that would be a problem is the server. If you don't have a good RAID going and some sort of offsite backup from the server that is backed up hourly then you should be in good shape. Course then your outbound backup routine is going to take up incoming bandwidth and so user performance is hampered. Ah the list goes on. Sounds like an interesting project but I think I would wait and use the R:Base C/S version. Coding in HTML and PHP is not as easy.
Jan Jan -----Original Message----- From: "MDRD" <[EMAIL PROTECTED]> To: [email protected] (RBASE-L Mailing List) Date: Thu, 13 Nov 2008 08:33:39 -0600 Subject: [RBASE-L] - Re: Server based app On more question on this server app with 100 users across the country. If one office had a computer crash could that corrupt the data on the server and cause problems for the 99 other users? Thanks Marc ----- Original Message ----- From: "Lawrence Lustig" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[email protected]> Sent: Tuesday, November 11, 2008 8:07 AM Subject: [RBASE-L] - Re: Server based app > << > I got a call from a guy that wants to have a medical billing app based on > his server > where over 100 doctors offices can log on and enter patient billings and > such. All > data will be kept on his server and he would charge a monthly fee. >>> > > > You have three choices: > > 1. Build a web based application where the database backend and web server > reside on your guy's site (or, more likely, in a rented data center > somewhere). His clients just need a web browser and password to get in. > Advantage: No software installation on client's sites. Disadvantage: Web > programming, especially good web programming, is a bear. The interface > will not be as rich as you are used to with R:Base. > > 2. Build a local, regular R:Base application. Install sufficient terminal > service servers at your guy's site to support the maximum simultaneous > number of log-ins. His clients use the terminal services client to open a > remote session on the host and do their work there. Advantages: Requires > no new programming skills, much easier to write. Disadvantage: You need > to manage that extra layer of terminal services, the terminal services > component probably won't scale as easily as a web system, you may have > contention issues if everyone is working in a single database instance. > > 3. Build a client server system using R:Base Client/Server or similar. > You run only a database server on the backend. Clients receive and > install the actual program on their PCs. The program attaches to a remote > database across the internet. Advantages: Least hassle on the backend, > you can leverage a lot of existing programming knowledge. Disadvantages: > Clients must install custom software which must be continuously patched > with new version, performance highly dependent on network connection > speed, you may have to reconsider some programmign paradigms to ensure > you're working with the smallest possible result sets (eg, no CHOOSE > statements with 10,000 options!) > > The "sexy" ways are 1 and 3, with 1 being pretty much the industry > standard at present. > > Hope this is helpful > -- > Larry > > -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.9.1/1781 - Release Date: 11/11/2008 8:59 AM
