Michael Scharf wrote:
Without journalling, you cannot have a ROLLBACK command.
And the semantics of UPDATE become UPDATE OR FAIL instead
of the default UPDATE OR ABORT. The difference is subtle,
but important.
There are other reasons to disable the rollback journal:
Suppose you want to create
Without journalling, you cannot have a ROLLBACK command.
And the semantics of UPDATE become UPDATE OR FAIL instead
of the default UPDATE OR ABORT. The difference is subtle,
but important.
There are other reasons to disable the rollback journal:
Suppose you want to create a database for querying
> I have been in contact with the developer of your flash filesystem
> and we are working on a solution now...
That really is excellent news. Thanks for your interest and effort. I look
forward to the solution.
DISCLAIMER:
This information and any attachments contained in this email message is
"Allan, Mark" <[EMAIL PROTECTED]> wrote:
>
> Apparently, yes the flash filesystem implements fully atomic writes, =
> indeed this was one of the features that made us choose this particular =
> filesystem. I know from development of our product that files are only =
> updated when the file is flus
14:14
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] disabling rollback journal
>
>
> "Allan, Mark" <[EMAIL PROTECTED]> wrote:
> >
> > our flash file system is 100% power-fail proof and thus the
> > journalling of the database for us is not
"Allan, Mark" <[EMAIL PROTECTED]> wrote:
>
> our flash file system is 100% power-fail proof and thus the
> journalling of the database for us is not required.
>
Without journalling, you cannot have a ROLLBACK command.
And the semantics of UPDATE become UPDATE OR FAIL instead
of the default UPDA
6 matches
Mail list logo
