Miguel Angel Latorre Díaz wrote:
Using v.3.0.5 and executing:
explain pragma page_size;
or whatever pragma is entered,
it throws an assert in function sqlite3VdbeSetNumCols called from main.c
line 1037:
sqlite3VdbeSetNumCols(sParse.pVdbe, 5);
Please write a ticket on this so that I don't forget
Using v.3.0.5 and executing:
explain pragma page_size;
or whatever pragma is entered,
it throws an assert in function sqlite3VdbeSetNumCols called from main.c
line 1037:
sqlite3VdbeSetNumCols(sParse.pVdbe, 5);
At 6:06 PM -0400 9/1/04, D. Richard Hipp wrote:
I fear that your patch has been overcome by events.
A subtle bug has been uncovered in another area
of locking which is going to require reworking large
sections of the commit/rollback logic. It is very
doubtful that your patch will survive this
On Wed, 1 Sep 2004, D. Richard Hipp wrote:
>Christian Smith wrote:
>> Created ticket #884, with patch against latest cvs:
>> http://www.sqlite.org/cvstrac/tktview?tn=884
>>
>
>I fear that your patch has been overcome by events.
>A subtle bug has been uncovered in another area
>of locking which is
Created ticket #884, with patch against latest cvs:
http://www.sqlite.org/cvstrac/tktview?tn=884
Minimal testing done, tested only within sqlite3 shell on Linux. A bit of
a hack. Mainly a RFC.
Quick transcript:
[EMAIL PROTECTED] sqlite]$ ./sqlite3 db
SQLite version 3.0.5
Enter ".help" for
Jakub, I must ask you to forgive me as only now noticed you were not the
sender of the tracker message for the bug. Sorry for the confusion (I
must stop replying messages late at night).
In the code I tested it was always the 113th row because I only created
a single table. I would assume it
Anyone get this error before? I got it with a sqlite backend, when
rebuilding a page when it gets to rebuilding index pages.
The 'hour' parameter (undef) to DateTime::new was an 'undef', which is
not one of the allowed types: scalar Params::Validate::__ANON__('The
\'hour\' parameter (undef) to
On Wed, 1 Sep 2004, Matt Wilson wrote:
>On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote:
>>
>> Add a new "BEGIN [TRANSACTION] FOR READONLY" statement, which begins the
>> transaction with a read lock only and doesn't allow the transaction to
>> even try to promote to a write lock.
OK, how about this suggestion.
Add a new "BEGIN [TRANSACTION] FOR READONLY" statement, which begins the
transaction with a read lock only and doesn't allow the transaction to
even try to promote to a write lock.
Then, the default behaviour for (default) non-readonly transactions is the
same as
Does anyone know of an OLE DB driver for SQLite?
Sincerely,
Matthew Schroeder
Software Engineer
PMA
517-788-8100 ext 310
Nuno, I have changed back to SQLite 2 and have my code ready to switch
to version 3 again if the bug is repaired. The thing happens when first
calling balance_nonroot, which is in your case always on the 113th row,
in my case on the 33th row and in the mail message
I agree.
Applications shouldn't worry about locking and timeouts. That would be the
job for the db core engine, returning as few (none ideally) busy status code
as possible.
Also, it is not always possible to decide which thread is better to rollback
since no info is provided about the status of
12 matches
Mail list logo
