--- In firebird-support@yahoogroups.com, James N Hitz <jamhitz@...> wrote:

>
> Hello
>
> I read somewhere that a good client/server application (say in a
> supermarket) should be able to survive both a server downtime as

well as

> a client downtime - implying; that is if I got it correctly; that the
> client application (in a retail store for example) should allow the

user

> to continue selling even if the server should happen to go down.
>
> Somebody please shed some light here. How would I survive a server
> downtime if my data (like prices, stock levels etc) are stored in a
> Firebird database at the server?
>

Well you can not deal with 'client downtime'. If the register isn't
working, it isn't working. What you can handle is comms problems and
server problems.

I don't think client-server is an appropriate methodology for a cash
register. It is inherently unreliable, reliable enough for most
problems, but good luck trying to sell your product with the
disclaimer that if the server network card fails they need to close
the shop for half an hour while someone runs down and installs a new one.

Firebird is just a database engine (a very good one at that), but not
some magical piece of software able to defy the laws of physics. If
the client has no way of contacting the server, the client can't ask
the server to do anything.

We have software with a similar requirement. The server may be
thousands of km away (across an internet connection, sometimes in
another state, and in at least one case another country). This is
probably 1000 times less reliable than a LAN.

If you need reliability, you can't require another machine to respond
to yours to function. You can not just assume that you can just issue
a select statement and get a response. It may take too long to come or
it may not even come at all.

Turn the big problem into two smaller problems. You need a local
database at each client, and you need to replicate the information to
and from the main server. When the client workstation needs some
information, it just looks at its local database. It reads prices,
stock, whatever is required from its local database. It writes its
transactions to its local database. Periodically, it sends any
transactions to the server and downloads new information for stock
levels and prices etc.

There are third party tools to handle replication, or it is reasonably
trivial to handle yourself using triggers to keep track of changes.

You can potentially avoid installing a Firebird service on each client
by using the embedded server. You will need to read the appropriate
readme files to make sure it is suitable to your needs.

Adam