On May 7, 2003 06:00 am, Boguslaw Brandys wrote:

> Hello,
>
> > >I have an application which connects to remote Firebird database
> > >server when possible and do some updates and also read some data to
> > > be stored in local database (which is simple a mirror of remote).
> > > I'd like to use fbembeded to avoid installing full server on client
> > > machine (Win98) , but fbembed.dll seems to be only server engine
> > > without client , and I can't use it as replacement for gds32.dll
> >
> > This was discussed in firebird-devel some time ago and I was one
> > who voted against client code in embedded engine.
> >
> > >(client library) for remote connections. So, I must load different
> > >library each time I connect to local or remote database, Am I right
> > > ?
> >
> > So far yes. Could you provide more strong reasons against
> > installing "normal" server on a client computer? If somebody can
> > manage to install FB in one place (remote machine), the person can do
> > it for other computers (client machines). FB is easy to install and
> > doesn't need hard maintenance for small DBs.
>
> Against installing "normal" (full) server on Win98 machine:
> - user could always shutdown server becouse he don't like Guardian or
> server icon on system tray
> - somebody could connect to such server throught TCP/IP
>
> If Guardian or server icon could be hidden and server maintenance moved
> for example into Control Panel (in Win98 of course , in WinNT/XP
> service is almost perfect solution) and if there will be a solution to
> not allow others to connect to server throught TCP/IP it will be
> sufficient for me (firewall is not accepted solution due to troubles in
> configuration)

The idea is that it should be an either-or ideology either you have a
full server and client, or you have embedded, rather then some mish-mash
of both. Having some databases on a central server and others local, is
asking for trouble.

I think what should be the goal though, is that when you install FB1.5 or
above, that TWO libraries should be accessable, fbembedded.lib and
fbclient.lib, so that the application developer can decide, at the linker
stage. I would rather have two .exe files, then adding a lot of extra
baggage to the fbembedded.dll file. After all, embedded is likely to run
on lower end machines, so adding an extra couple of MB to the foot-print
may not be a good idea.

> > As long as the engine cannot do heterogeneous queries, partial
> > local mirror seems to be useless. Local cache for individual tables
> > can be made by much lighter engines (including in-memory tables and
> > text files). Well-designed client application doesn't abuse network
> > wire and even 10Mb coax is more than enough.
> > If we are talking about the case when remote database is over low-
> > bandwidth channel... I'd recommend full (or application-depended
> > partial) replication to local workgroup server.
>
> Remote database is over very-very low bandwidth channel (modem
> connection) , but the main problem are costs.
>

I think the real solution here is 3-tier rather then 2-tier, for example
a web based application, where the database and web servers are connected
by wire, and the "clients" use dial-up to connect to the web server.
This would allow the (database)server/client to operate over a fat pipe,
while the end-user is on a narrow pipe. Another solution, that might
work well is to put the app on a Unix box, run an X based app, where the
display "server" is on the end of the modem connection. Again the
database and application are connected via a fat pipe, and the display is
rendered on a narrow pipe.

Replication always presents issues, the usual issue is synchronization,
trying to keep all of the copies of the database reasonably up to date.