agarzotto wrote:

> Some databases allow to write a transaction log to a different drive
> so that if the drive containing the database crashes, a backup can be
> restored and all transactions since the backup can be recovered using
> the transaction log.

There are several answers to this. The first is probably the obvious -
if the data is critical, the the machine it is running on would be using
a RAID disk, so allowing 'hot' handling of live data. The second option
is 'replication', where there is more than one set of hardware, each
maintaining a live copy of the data.

Firebird supports an internal SHADOW facility which will allow it to
maintain two local copies of the data, and the second copy can be
accessed should the first become corrupt. This should be viewed as a
secondary method of 'backup', depending on the level of availability
required.

> Is it true that Firebird does not support a transaction log? If it
> does support it, how to enable it?

Firebird has all the facilities in place to provide a transaction log
which are used by a number of add on packages for both replication and
logging. In addition the new backup facilities will make this a reality,
as the GBAK package is augmented with an incremental backup facility. (
I sat through the paper on it at the Firebird Conference )

> If there is no such thing as a transaction log, is there any other way
> to cope with the problem (DB destroyed, backup does not contain all
> transactions)?

Firebird is designed for ease of use, and does not 'require' a DBA so in
it's of the shelf form it just works. Addressing the problems of users
doing a DROP TABLE or other useful facility requires a little more care
in the application level.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services