On 28 October 2016 at 02:53, Rolf Ade wrote:
> Another plea, since I'm already writing: It isn't immediate and without
> any doubt clear, how the "timeout" and the "busy" methods play together,
> if both are used. I suspect, the timeout, if given, determines, how long
> it
i was developing Rails App
$ rails c
$ Article.connection
then found this bugs
/Users/*/.rvm/gems/ruby-2.3.1/gems/activerecord-5.0.0.1/lib/active_record/connection_adapters/sqlite3_adapter.rb:27:
[BUG] Segmentation fault at 0x000110 ruby 2.3.1p112 (2016-04-26
The documentation of the busy method at
http://sqlite.org/tclsqlite.html#busy
should be more specific, with regards of the arguments of the Tcl
callback procedure.
The documentation currently reads:
The "busy" method, like "timeout", only comes into play when the
database is locked.
Hi,
I expected the test case below to print 5679, but it prints 1235
instead. I tested under a few versions including 3.15.0. It's a bit of a
corner case and I worked around it in my application, but I guess it's a
bug.
CREATE TABLE foo (bar INTEGER PRIMARY KEY AUTOINCREMENT);
INSERT INTO foo
As soon as I hit Send, I thought of something. This only holds until
you actually read the destination database. So in my example code,
after the check that the database contains the right data
("e\nf\ng\nh" bit), another page_size check will show 4096 instead of
1024. So the window for this to
Here's an example code for reference:
http://pastebin.com/pQdfkneR
I just noticed that if you use sqlite3_backup() where the source
database page_size isn't the same as the destination database
page_size, after a successful backup the destination database
continues to report the page_size from
I'm playing around with WAL mode here for the first time, along with some of
the pragmas, and I'm getting some weird results. I was hoping someone could let
me know if I'm missing something, or if yes, it is indeed weird.
For starters, I'm looking at the journal_size_limit pragma.
* Richard Hipp:
> (1) You should be able to drop in SQLite 3.15.0 (or any other release
> after 3.8.2) in place of SQLite 3.8.2 and everything will continue
> working just fine. The only changes will be that the applications
> will run a little faster. We carefully test backwards compatibility.
Yup, thank you very much.
-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Richard Hipp
Sent: Thursday, October 27, 2016 11:21 AM
To: SQLite mailing list
Subject: Re: [sqlite] Minor pragma doc update request
On 10/27/16, David
On 10/27/16, David Raymond wrote:
> Minor documentation update request for the pragma page's entry for
> incremental_vacuum:
> http://www.sqlite.org/pragma.html#pragma_incremental_vacuum
Is the draft change at
Am 27.10.2016 um 14:00 schrieb sqlite-users-requ...@mailinglists.sqlite.org:
On 10/25/2016 01:25 AM, Christian Czech wrote:
>We have a problem with the latest stable release of SQLite. When
>compiled for 32 bit under windows and vacuum a database file larger
>than 2GB, memory storage usage gets
Minor documentation update request for the pragma page's entry for
incremental_vacuum:
http://www.sqlite.org/pragma.html#pragma_incremental_vacuum
Currently:
"PRAGMA schema.incremental_vacuum(N);
The incremental_vacuum pragma causes up to N pages to be removed from the
freelist. The database
Hi Rob,
I can see your point, but couldn't tell you if this should be considered a
bug or not.
Probably only DRH can tell you that.
RBS
On Thu, Oct 27, 2016 at 8:21 AM, Rob Golsteijn
wrote:
> Hi RBS,
>
> Re-introducing mytable in the sub-select is a workaround (and
Hi RBS,
Re-introducing mytable in the sub-select is a workaround (and to get the same
semantics in the general case I have to use the same row from the inner mytable
and outer mytable). As indicated in my original message I already have a
workaround for the issue.
The intention of my post was
14 matches
Mail list logo