It was a typo. I was setting fullsync when the correct pragma name is
fullfsync.
On Fri, Sep 26, 2008 at 9:50 AM, Jeffrey Rennie (レニー） <[EMAIL PROTECTED]>wrote:
>
> 2008/9/25 D. Richard Hipp <[EMAIL PROTECTED]>
>
>>
>> You are confusing the statement journal
2008/9/25 D. Richard Hipp <[EMAIL PROTECTED]>
>
> You are confusing the statement journal with the rollback journal.
> The statement journal has nothing to do with database recovery - that
> is the task of the rollback journal. So the statement journal can be
> deleted at will without damaging th
then your DB will be corrupt.
It also makes it much harder to debug issues on clients' machines, because
you can no longer just say "send me all the files in the folder yadayada..."
2008/9/25 Jeffrey Rennie (レニー） <[EMAIL PROTECTED]>
> Small correction: I'm using sqlit
Small correction: I'm using sqlite version 3.5.9.
On Thu, Sep 25, 2008 at 1:08 PM, Jeffrey Rennie (レニー） <[EMAIL PROTECTED]>wrote:
> I'm seeing this happen on Mac OS X, after the user hard reboots his
> computer. I'm compiling with -DHAVE_FULLFSYNC=1 and running wi
ion?
Sincerely,
Jeffrey Rennie
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Are there any other processes or threads trying to open your db file while
you run your tests?
On Mon, Jun 23, 2008 at 9:48 AM, Andrea Connell <[EMAIL PROTECTED]>
wrote:
>
>
> >> The program took 47 seconds to run, but the results only account for
> >> .39 seconds
> >
> > Most likely all the time
? In other words, is there a simple mutex in the sqlite* or
a read/write lock?
Sincerely,
Jeffrey Rennie
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
On Mon, Apr 14, 2008 at 9:48 AM, Chris Tracy <[EMAIL PROTECTED]> wrote:
> >> inserted into the database in ascending order, and where there may be
> as
> >> many as 500 hID entries for each timestamp. After a while, this table
>
> > Have you considered making timestamp a PRIMARY KEY?
> >
> > So
I guess changing the ORDER BY clause from ASC to DESC or vice versa is
not sufficient for your needs?
On 10/4/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
>
>
> sqlite3_step() is great for scrolling forward through a result set.
> Is there a way to scroll backwards?
> If not, did anyone try
Here's a naive solution, which requires some programming language
around the SQL:
BEGIN TRANSACTION
n = (SELECT count(*) from table)
i = RandBetween(0, n)
row = (SELECT * from table LIMIT 1 OFFSET i)
END TRANSACTION
I'm posting this because I suspect that this naive solution isn't
correct, but I
On 2/9/07, Dennis Cote <[EMAIL PROTECTED]> wrote:
Jeffrey Rennie wrote:
> I think the code in the next higher stackframe may be the culprit.
>
> I inserted a new line of code at vbde.c:2374 so it now reads:
>
>if( pOp->p2 ){
> assert( i==1 );
> sql
LITE_FULL as I had expected.
On 2/9/07, Dennis Cote <[EMAIL PROTECTED]> wrote:
Jeffrey Rennie wrote:
> Debugging the code:
>
> winWrite returns SQLITE_FULL, which propagates back up the stack to
> vdbeaux.c, line 1270, in function sqlite3VdbeHalt(Vdbe *p):
>
>
is? Has it been fixed in more recent releases?
On 2/9/07, Jeffrey Rennie <[EMAIL PROTECTED]> wrote:
It looks like the journal file itself is running out of disk space. It
has only 512 bytes, even though I'm creating lots of tables in the
transaction, and the DB file itself is stuc
th a db of
size 0 bytes.
There is 6144 bytes of free disk space on my drive.
On 2/9/07, Jeffrey Rennie <[EMAIL PROTECTED]> wrote:
Thanks Artem. Your description of events agrees with the documentation
and what I would expect to happen, but not with what I'm observing in
running
on as you make
commit, there is a records of changes in a DB. During
this moment there can be an ending of an empty space
on volume, then sqlite will return an error and will
roll away changes.
--- Jeffrey Rennie <[EMAIL PROTECTED]> wrote:
> What happens, and/or what is supposed to happen
atements at the time of
the COMMIT TRANSACTION.
I'm using version 3.3.4 on Windows.
Thanks,
Jeffrey Rennie
16 matches
Mail list logo
