<< 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
