Subject | Re: [firebird-support] Log file problem |
---|---|
Author | Helen Borrie |
Post date | 2004-12-17T08:21:57Z |
At 04:52 AM 17/12/2004 +0000, you wrote:
disk. (On Windows, don't judge by what the filesystem tells you about file
growth. Windows doesn't refresh that information until the file is
physically closed.)
Why would you want to shut down the server while a client is attached?
as "multi-generational architecture". If a client submits a legal request,
and the change is allowed, the server writes a new record version to
disk. If the change is subsequently committed, the new record version
becomes the latest committed version and replaces the old version. The old
version then becomes garbage that the server will clean up
eventually. Until the actual commit succeeds, the new record version does
not change database state.
If you crash the server, the uncommitted work will be still on disk but its
context is lost. Firebird won't let you carry on and commit work that was
posted before the crash, since the restarted server has no way to recover
the context of those pending record versions in relation to database state
as it was at the moment you stopped the server. Eventually they will just
get cleaned up and disappear.
./heLen
>I have a program which is written with firebird API, I've tried toNot true. With Forced Writes enabled, the data is written immediately to
>set the option of database Forced Writes to Disabled and then insert
>several numbers of record and suddently shut down the server, surely
>the data is lost. I know that the data is physically write to db only
>when the program disconnect to the db
disk. (On Windows, don't judge by what the filesystem tells you about file
growth. Windows doesn't refresh that information until the file is
physically closed.)
Why would you want to shut down the server while a client is attached?
>, but the main point I want toThere is no log file for database state changes. Firebird has what's known
>ask is is there a log file write down all the data that is not yet
>save to the db, so that we can restore it?
as "multi-generational architecture". If a client submits a legal request,
and the change is allowed, the server writes a new record version to
disk. If the change is subsequently committed, the new record version
becomes the latest committed version and replaces the old version. The old
version then becomes garbage that the server will clean up
eventually. Until the actual commit succeeds, the new record version does
not change database state.
If you crash the server, the uncommitted work will be still on disk but its
context is lost. Firebird won't let you carry on and commit work that was
posted before the crash, since the restarted server has no way to recover
the context of those pending record versions in relation to database state
as it was at the moment you stopped the server. Eventually they will just
get cleaned up and disappear.
./heLen