Subject Re: FB 1.5 and client connection
Author Adam
> One more question:
> My company's software is purchased by clients all over the world,
> mostly in USA.
> Our company maintains an update website where clients can dnld the
> latest release.
> The current app uses a PC database and the EXE and all data files
> in the same dir.

Smells a bit like a job for embedded server?

> To run the current version offsite, our clients copy the whole app
> folder from the corporate PC to the offsite PC.
> The new version of this app uses FB152 SS. I understand that
> (reinstalling) the new app to an offsite network will be just a
> more complicated than copying a folder.

Firebird is completely interchangable. Your application currently
uses FB152 SS, but with no change in code it could use FB152 CS or
with only a different connection string it could use FB152 Embedded

> What I am trying to learn is
> what is the absolute minimum we would have to install (if anything)
on a
> client PC in order to run a single EXE from a PC that is also the
> server machine.

If they have the Firebird server installed, I think the client
library is already in an environment path so no client install is
necessary. To keep it simple, we deploy the fbclient in the
application folder regardless of which machine is the server.

> We are still developing the new app and when we test it, we copy
> EXE, a set of UDL files, and the fbclient.dll to the client test
> machine. The dev PC is also the FB server PC in a p-t-p network.
(If we
> run the EXE from a network PC, it's very slow - probably caused by
> virus software which we will resolve when we have time.)

Firebird does not have an ideal over-the-wire protocol. It does not
compress or encrypt traffic, so performance that is acceptable in a
normal client server environment may be unacceptable over a broadband
connection. 3rd party products such as Zebedee can be used to create
a secure tunnel and they can do on the fly compression.

Running the exe over the wire is slow because it needs to transfer
the entire exe plus any dlls etc that are implicitly used. Over a
slow connection this is exagerated.

But the client server architecture doesn't really scale that well
over slow connections, you really need to think about using a tier
architecture. Alternatively you can use a terminal services style
delivery method, hosting the application and database on high powered
servers in a secure data centre, and sell your product as a service.
We find that this gives a lower risk to the buyer, if our system does
not work out for them then they haven't wasted money on their own
hardware infrastructure, and it means we don't need to get into
fights with their techos about remote connectivity for support. This
is however getting OT.

The dll is all the client needs to connect to Firebird. In embedded
mode, the dll just happens to contain a SuperServer engine.