[EMAIL PROTECTED] wrote:
of course, it doesn't help that apparently I'm the only one on the
planet that has ever observed this behavior. I'm quite sure that I
didn't imagine it, however, as well as the several hours it took me to
restore all that data from backups.
Joe,
This kind of
On Jul 18, 2006, at 17:04 UTC, Dennis Cote wrote:
> Can you repeat this test and reliably loose the data (i.e. is this a
> repeatable failure)? If it is doing what you say it is, it should be
> easy to reproduce.
No, I had done the same thing many times and never lost data before. Also, of
[EMAIL PROTECTED] wrote:
It seems unlikely. It wasn't a system crash; actually, I just killed my
application process. Anything the app had written out to disk already, should
have still been there after the restart.
It's very disturbing -- I'm hearing that SQLite should automatically flush
[EMAIL PROTECTED] wrote:
>
> It's very disturbing -- I'm hearing that SQLite should automatically flush to
> disk, and that what I observed shouldn't be possible. I'm relying on it to
> keep my data safe (backups notwithstanding). Yet in practice, it really did
> roll back two days' worth of
On Jul 18, 2006, at 16:40 UTC, Nuno Lucas wrote:
> Any chance of being the OS file system that "rollbacked" the files
> after the crash?
It seems unlikely. It wasn't a system crash; actually, I just killed my
application process. Anything the app had written out to disk already, should
have
On 7/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I've just lost a couple of days' worth of data when my app crashed. (Well, the
data wasn't a total loss thanks to backup plans, but the database itself
essentially reverted to its state of 2 days ago.) This is despite my app doing
a
On 7/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
That's interesting. What is "the F_FULLFSYNC syncing method" (since I am
running on Mac OS X)? For what it's worth, PRAGMA FULLFSYNC returns 0 on my database.
I believe the F_FULLSYNC syncing method is a method implemented by
Apple
On 7/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I'm using the Commit method. I can try executing the COMMIT SQL command
instead. Though as another poster pointed out, I shouldn't really need to do
either, since I'm not using BEGIN.
The REAL SQL Database (the REALbasic database
On Jul 14, 2006, at 23:43 UTC, Kees Nuyt wrote:
> The syntax descriptions about PRAGMA synchronous= could shed
> some light. http://www.sqlite.org/pragma.html#modify
> Note: The default for the "synchronous" PRAGMA is version
> dependent.
That's interesting. What is "the F_FULLFSYNC syncing
On Jul 15, 2006, at 00:27 UTC, Will Leshner wrote:
> Since I happen to know this is being done with REALbasic, are you
> calling COMMIT yourself, explicitly, or are you calling the Commit
> method? I suppose there could be a bug in the REALbasic plugin that is
> somehow preventing a commit from
On 7/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Yet my observations indicate that the database hadn't written anything to disk
in two days (or if it had, it somehow decided to roll back the last two days'
worth after the crash). Any insight on that?
It really sounds like you've
On Jul 14, 2006, at 22:53 UTC, Kees Nuyt wrote:
> How many SQL commands are in your typical transaction?
One.
> Do you start them with a "BEGIN" ?
No, I'm using implicit transactions.
> If you never do a "BEGIN", every SQL command is
> one transaction, and "COMMIT" has no meaning.
Yes, I'm
On Jul 14, 2006, at 22:22 UTC, Will Leshner wrote:
> COMMIT should write the data to disk. Did you check errors after the
> COMMIT to be sure there wasn't some kind of error?
Yes, I checked, no error was ever reported. Also, I very clearly had all my
data accessible while the app was running,
On 7/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
It's acting as though all the changes were held in memory, or somehow
journaled, and when the crash happened, the changes were all lost or rolled
back. What I need is a way to force the database to save its data to disk
while my app
I've just lost a couple of days' worth of data when my app crashed. (Well, the
data wasn't a total loss thanks to backup plans, but the database itself
essentially reverted to its state of 2 days ago.) This is despite my app doing
a COMMIT after every modification of the DB.
It's acting as
15 matches
Mail list logo
