Okay, I blocked the sqlite-users at sqlite.org address in the to address
so if it is sent alone, it will be blocked.
On Mon, Mar 2, 2015 at 9:46 PM, Mike Owens wrote:
> Oh okay. I see. I'll look into it.
> On Mon, Mar 2, 2015 at 9:23 PM, Darren Duncan
This is a test. The sqlite-users at sqlite.org address has been blocked.
Only sqlite-users at mailinglists.sqlite.org should be allowed through.
> On 2015-03-02 7:10 PM, Mike Owens wrote:
>> The problem is that this is the very bone of contention in the reply-to
>> religious war. Is it not? I may be wrong, but I thought this is the very
>> setting that people get so defensive about changing. As we have it n
> On 2015-03-02 6:14 PM, Mike Owens wrote:
>> On Mon, Mar 2, 2015 at 5:27 PM, R.Smith wrote:
>>> Ah, thank you, all makes sense now. If you change the first option to YES
>>> then nobody else's quirky reply-to headers will get into the list, and
>>> happy with the explanation - but I am wondering - is this done and
>>> Is there any chance we might re-open the discussion now that real-World
>>> scenarios have set in?
>>> It's an extremely minor irritation and will cause a
On Mon, Mar 2, 2015 at 5:24 PM, Darren Duncan
> As near as I can tell, the Reply-To header from this list only contains
> sqlite-users at mailinglists.sqlite.org and does not also contain
> sqlite-users at sqlite.org so therefore I don't see the problem you're
> stating. But if it
ing there is not a single good reason to keep the situation (unless
> someone can show the opposite).
>> On 2015-03-02 10:37 AM, Mike Owens wrote:
>>> For what it is worth, the move to mailinglists.sqlite.org is a result of
>>> the Mailman web interface h
For what it is worth, the move to mailinglists.sqlite.org is a result of
the Mailman web interface having to be hosted under the following two
1. It must be on port 80
2. It cannot be on sqlite.org port 80
I explained this reasoning in a previous email. The short version is
We are in the process of moving mailman from sqlite.org:8080 to
mailinglists.sqlite.org. The reason for this is that sqlite.org runs on a
different web server (althttpd) than the mailman management (Apache) and so
we originally used port 8080 for mailman. Well, port 8080 does not work for
It seems to me that this should be invalid as COUNT(id) does not refer to a
valid field in the subquery's column list. I would vote for throwing an
error as it seems that wrong. Since its been over six years since I wrote
that query, I don't know what I was thinking at the time.
Sent from my
FWIW, there is a second edition of the Definitive Guide to SQLite,
apparently coming out in Nov:
Allen Grant is the author doing the work. I don't have any details other
than that. I hear he's a good guy for the job though
On Mon, Apr 14, 2008 at 8:45 AM, Martin Jenkins <[EMAIL PROTECTED]> wrote:
> Mike Owens wrote:
> > I've been lobbying Apress to release the book in electronic form for
> > free. It's currently under consideration, but I've not heard anything
> > back yet.
On Sat, Apr 12, 2008 at 9:36 AM, Rich Shepard <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Apr 2008, Amit Uttamchandani wrote:
>I second the recommendation of Mike Owens' "The Definitive Guide to
> SQLite" for detailed insight on this system. And it does have the worst
On Wed, Apr 2, 2008 at 11:59 AM, Evans, Mark (Tandem) <[EMAIL PROTECTED]> wrote:
> One other consideration: If the query or update has to walk a large
> range of rows, there's no way for the core to tell the VTM
> that it's done accessing a given row as it sweeps the cursor
> forward. You
Here's a link to the source:
BTW, I totally missed the new bitvec recently introduced in the latest
version to track dirty pages. This pretty much removes the previous
constraints I mentioned on large databases, reducing memory
The main reason why SQLite's practical limit is in the 10s of GBs as
opposed to TBs (theoretical) is due to how it tracks dirty pages. This
is described in the "Appropriate Uses" page
(http://www.sqlite.org/whentouse.html) but I'll rehash it here for
convenience. SQLite tracks dirty pages with a
One suggestion I would make is to keep your blobs in a separate table,
or at least in a table in which you don't anticipate searching on
anything but the primary key. The reason is due to how SQLite manages
blobs. If a blob grows larger than a page's payload (approx page
size), it will spill over
I would guess PRAGMA synchronous. Per documentation:
"In SQLite version 2, the default value is NORMAL. For version 3, the
default was changed to FULL."
Try setting it to NORMAL for v3 tests and see what that does.
On Thu, Mar 27, 2008 at 11:06 PM, Richard Klein
Starting yesterday afternoon we seemed to experience some serious
delays in mailing list distribution. It has been difficult to
determine what the actual cause is, as there has been no configuration
changes in either the mailing list of mail server.
It *appears* as if this may have been a
The SQLite mailing list has been moved over to Postfix and GNU Mailman. Please
do not use the ezmlm mail accounts to modify your subscription status from this
You can now configure your list status and options via the Mailman
sqlite-users mailing list
This is not a link issue, but a compiler one. SQLite is ANSI C, so you
should compile it with gcc. It will still be usable within your C++
library/project, as sqlite3.h qualifies all functions extern "C".
For example, given a C++ file main.cpp:
More of a half is about SQL generalities, an a quarter a copy-paste of the
on-line manual without more comment. At the end, the horrific index i've
For the record, Apress had the index generated by a third party. I've
used the index myself recently, and frankly it worked for me -- I
Hey, sorry I'm a little late on this one (as usual).
On 2/3/07, David M X Green <[EMAIL PROTECTED]> wrote:
I am new to this but are these issues those of trying to get it to do what sqlite
it > is not designed for. I quote the book
The Definitive Guide to SQLite - Chapter 1 --- Networking
This was posted previously, but in case you missed the subject line,
here is a restatement.
Google and O'Reilly honored five open source people whose
contributions over the past year have been exceptional in five
categories: Communicator, Evangelist, Diplomat, Integrator, and
Hacker. Richard was
On 5/18/05, Gerhard Haering <[EMAIL PROTECTED]> wrote:
> On Wed, May 18, 2005 at 10:22:39AM -0500, Mike Owens wrote:
> > What about sqlite3_set_authorizer()? Implement a callback function and
> > monitor changes in transaction state for each connection object: [...]
Mail list logo