Subject | Re: [firebird-support] Re: Improvements in the last year |
---|---|
Author | Artur Anjos |
Post date | 2004-05-28T22:22:08Z |
Augey,
Ann already answer you most of your questions, and I will just put some
more comments:
was not using it (as by default in Interbase), you will have corrupt
.log files, bringing you to the exact point.
Firebird does not use .log files, but this doesn't mean that it doesn't
have any kind of control when the database is shutdown abruptely. Ann
did a very good presentation in Fulda last year (2003), regarding the
way this control is done. Documentation from last year is available for
free in http://www.firebird-conference.com
Take a look at it: in resume, Firebird keeps some flag's to control
transactions in Limbo, and it will clean up the mess the first time you
connect to the database. In Firebird, we just don't need a transaction
log file for this specific purpose.
Suggestions:
If you will not use a server installation, take a look at the embeded
server. It's great for single user applications, and it will lock the
file for you. See the readme.txt and Release Notes for more info about
using it.
If you are using server installations, just take away direct access to
copy database files, and create some tools for the user to achieve this
(stop firebird, copy the file, start firebird). Take care with this:
other databases will be shutdown as well. (Why your users need to copy
the database file so often?)
"does this typically solve the problem": well, Firebird will do his job,
and it will instruct the OS system to flush the cache. There's nothing
more it can do. After this, the complete answer should be provided by
Microsoft. :-)
Artur
Ann already answer you most of your questions, and I will just put some
more comments:
> As far as the machine being powered off or some sort of unplannedSo, the problem must be that you are not using Forced Writes. If sysbase
> termination, sybase deals with this by using the .log file which logs
> every transaction in a linear fashion which basically causes the worst
> case scenario to be one lost record rather than any data corruption if
> the machine is powered off during a transaction. (and im sure they
> also use forced writes).
was not using it (as by default in Interbase), you will have corrupt
.log files, bringing you to the exact point.
Firebird does not use .log files, but this doesn't mean that it doesn't
have any kind of control when the database is shutdown abruptely. Ann
did a very good presentation in Fulda last year (2003), regarding the
way this control is done. Documentation from last year is available for
free in http://www.firebird-conference.com
Take a look at it: in resume, Firebird keeps some flag's to control
transactions in Limbo, and it will clean up the mess the first time you
connect to the database. In Firebird, we just don't need a transaction
log file for this specific purpose.
> My question is, why doesn't firebirdAnn answer you this.
> use exclusive file locking when it first opens the filehandle for the
> database file in a similar fashion?
Suggestions:
If you will not use a server installation, take a look at the embeded
server. It's great for single user applications, and it will lock the
file for you. See the readme.txt and Release Notes for more info about
using it.
If you are using server installations, just take away direct access to
copy database files, and create some tools for the user to achieve this
(stop firebird, copy the file, start firebird). Take care with this:
other databases will be shutdown as well. (Why your users need to copy
the database file so often?)
> You had mentioned a difference between an InterBase database and a"simple way": Gfix.
> FireBird database and forced writes. Would there be a simple way to
> convert our databases to FireBird or just simply change the forced
> writes parameter? And if so, does this typically solve the problem
> with the power down scenario?
"does this typically solve the problem": well, Firebird will do his job,
and it will instruct the OS system to flush the cache. There's nothing
more it can do. After this, the complete answer should be provided by
Microsoft. :-)
> We are using Windows 2000 Pro and Windows XP Pro out in the field, btw.Great.
Artur