>
> I totally agree. But, in very simple application,
> using server based database would make it so
> complicated, particularly when some troubles raised.
> Let say, if firebird server is halted, but users dont
> know, then he/she has to start it up again. But, not
> all users are having this skill.

Lets address this problem first.

If Firebird is installed as a Service, then Windows will start is
automatically when it boots up. You can set the service to
automatically restart upon failure. There is also a guardian
application (for Superserver only) that monitors that process, and if
it dies then guardian will restart it.

The following command will bring up the services window where you can
set all this.

%SystemRoot%\system32\services.msc /s

So as far as the end users are concerned, the server is always running.

Secondly, a server halt is not what I would determine to be a normal
thing. If you are experiencing crashes, then it is either a bug in
Firebird (which need to be resolved), a bug in a UDF you have used, or
a hardware related problem.

When dealing with a multi-user scenario, you need to forget the
concept of halting servers. It is like me sharing the printer attached
to this machine. It works fine when my machine is on, but if I switch
it off, then no-one can print. Starting and stopping a database server
is not like starting or stopping Word or Excel. It affects other
users, and so it would be advisable that your users do not even have
the permissions to start or stop the service, let alone the skill.

In most databases, one doesn't just go in and pull it offline. There
is normally a tonne of paperwork that must be filed first and
appropriate memos go out with appropriate notice and someone high ups
approval before you would even think about shutting it down.

> >
> > Access doesn't have this problem?
> >
> > Google for data recovery from MS Access if you think
> > it is really
> > bullet proof. If you want it to be "as secure" as MS
> > Access (but do
> > not confuse this with secure), then you should be
> > able to emulate it
> > using some third party file system level encryption
> > utility, of which
> > their are many.
>
> Hehehe :) Thanks :) I used to think that MS Access DB
> is cool:
> - single file (although need MDAC to access)
> - has a password protection (although crackable
> easily)
> - can be shared using SMB
>
> May be not all of these 'features' is correct. But,
> however, i see people are doing that.

Of course the data is shipped from the 'server' share to the client,
so don't start playing with GB sized databases. Those who started on
databases like Access or Paradox are generally those who are blown
away by the new performance they can achieve when they don't have to
wait for an entire table to cross the network.

No one in this list will tell you that access has no use, but when
Microsoft also have SQL Server and the 'free' cutdown MSDE engines, it
should ring a bell that says that not even Microsoft believes that
Access is appropriate for all scenarios. You are still actually
relying on the SMB Service being running (lanmanserver?) so I do not
see how this is less reliable than the firebird service being running.
Firebird supports single or multiple files.

I am not aware of any large DBMS that requires the client application
has any file system permissions to the database file. It would be too
much of a headache to setup and a security nightmare. Imagine if a
bank had to grant write access to the database files to anyone who
accepted Visa or Amex?

Adam