At 09:25 PM 19/03/2003 +0000, you wrote:

>Hi All,
>
>Thanks in advance for the thoughts on this one...
>
>We are having an application developed out-of-house. It replaces an
>older application that was poorly designed for LAN (and WAN)
>environments. This replacement app has been hailed by the developers
>as following a client-server architecture. When I take a close look
>at how it is installed, I am concerned that such is not the case.
>
>Installing goes like this:
>1. Install InterBase on the Server (set up certificates, etc.)
>2. Install app server-side components on the same Server (Compaq
>ProLiant 3000)
>3. Install client-side components on the clients.
>
>Now that looks correct so far, as a general rule (in my mind).
>
>A close examination of what constitutes server-side components and
>what are client-side components in this case has me puzzled. It looks
>like this:
>1. InterBase and the GDB file are on the Server
>2. The application executable (Delphi 6 app) are also installed on
>the Server
>3. User config files, such as grid config, workstation config, etc.,
>are stored on the clients.
>
>Concerns:
>Having the 6.5 MB executable on the Server doesn't make sense in my
>mind. With that configuration each client must pull the executable
>across the network as well as the data. That seems like a poor client-
>server design (at the basic app level) for one and, it also seems
>like a generally inefficient model for network performance,
>especially where the customers have dial-up WAN situations.
>
>My Design Idea:
>1. Install InterBase (and the GDB) on the Server
>2. Install any absolutely required server-side components for the app
>on the Server
>3. Install all binaries (the EXE, DLLs, etc.) on the clients
>4. Use the BDE and ODBC to point to the Server share

Gary,
For client/server, the deployed setup is wrong and yours is closer to the
right one. (Except point 4: the server can NOT be a share; and the BDE
is to be avoided on IB versions > 5.x, as it is now deprecated). A
"client" is a client of the database.

For an n-tier architecture, you could find the application-layer exe (host
application) on a server, although desirably not the same server machine
that is serving the database. Clients do not run instances of the host
application - they are clients of the host application, not of the
database. The client library (gds32.dll or its equivalent) would be
instantiated on the application server and would connect to the server on
behalf of the clients.

Where the database server and the application server were on the same
machine, the app server would address the server as localhost (local
loopback connection). Clients would each have their own copy of a client
program which would connect to the server application, not to the database.

A variant of n-tier is an intranet application. In this architecture,
intranet clients access the host application via a web browser. On
Windows, the host application might well be an ISAPI module.

If you have "User config files, such as grid config, workstation config,
etc." then these don't belong to the database, they pertain to the
application. For client/server, clients need a copy of gds32.dll in their
system directory and to have the IP address of the server in their Hosts
file. In the n-tier case, there would be no database client configuration
on the client machine (unless clients were *also* able to access the
database as database clients, from a local copy of a client tool like
FbWorkbench or gfix).


If the application isn't n-tier, then client workstations need to run the
client application in their local memory space. In the case of diskless
workstations, the exe would be read from another disk somewhere in the
network - but having this resource on the same machine as the database
server isn't a great idea from the perspective of resource
allocation...still, if you are an all-Windows site, it's pretty unlikely
that you have diskless workstations...

heLen