Hi,
I think R:BASE Client/Server is not allowed on Internet ! But only Intranet.
So option 3 is not valid. Maybe the R:BASE people can confirm this.
Marco
----- Original Message -----
From: "Lawrence Lustig" <[EMAIL PROTECTED]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Tuesday, November 11, 2008 3:07 PM
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
