Re: [sqlite] Cannot write to db if it is already open for reading with shared cache

[Richard Hipp]

On Mon, Aug 4, 2014 at 4:08 PM, Кривопалов Юрий 
wrote:

> Hello.
> I getinng an error in a following scenario. I think such a behaviour is
> not obvoius.
> 1. Enable shared cache
> 2. Open db with SQLITE_OPEN_READONLY
> 3. Open same db again with SQLITE_OPEN_READWRITE
> 3.1 Try to insert for last connection.
> = You get SQLITE_READONLY error.
> If swap 2 and 3 steps, when all works without errors.
>

"Shared cache" means that two or more database connections are sharing the
same file descriptor to the database file.  All database connections use
which ever one opened first.  If you open the readonly connection first,
then all other connections sharing that same cache will also be read-only.

Why are you using shared cache?


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Cannot write to db if it is already open for reading with shared cache

[Кривопалов Юрий]

Hello.
I getinng an error in a following scenario. I think such a behaviour is not 
obvoius.
1. Enable shared cache
2. Open db with SQLITE_OPEN_READONLY
3. Open same db again with SQLITE_OPEN_READWRITE
3.1 Try to insert for last connection.
= You get SQLITE_READONLY error.
If swap 2 and 3 steps, when all works without errors.

Code example: http://pastebin.com/ubg0mBrN
Output: insert - 8

I can't find any mention of such a behaviour in documentation. So I think it is 
bug in implementation or in documentation.
I have been working on a large enterprise application and when someone enabled 
shared cache globally, investigation for READONLY error in my code took a lot 
of time.

Regards, Yuri Krivopalov
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Expected behaviour of COUNT with no GROUP BY?

[James K. Lowden]

On Mon, 04 Aug 2014 18:36:24 +0200
RSmith  wrote:

> > I guess I still find the combination of COUNT
> > without a GROUP BY to be unintuitive, but at least I know why now. 
> 
> As far as I know, there is no requirement for a group by clause for
> any of the functions really, a table or any SELECT result set is by
> definition "a group" (or should I say "the Group"), and unless a
> "group by" is explicitly stated, the table/result-set is itself the
> group and all group functions (aggregates functions) should work on
> it. 

Depends on what you mean by "no requirement".  

It may help to remember the that "the group" is the set of
*columns* that constitute the argument to the SELECT operator.  When
you say, 

select count(*) from T

no columns are mentioned.  There is no group (or, the group is empty),
and the count refers to the number of rows that meet the WHERE criteria
(in this case, all of them).  When you say, 

select count(*), A from T group by A

the meaning is the count of rows in T for each unique A.  SQL *requires*
the columns to be restated in the GROUP BY clause.  I think you're
implying the language could have been unambiguously defined without
GROUP BY because the required information is present in the SELECT
column-set.  That's true, but the language for which there's "no
requirement" is not the SQL currently defined.  

When you say, 

select count(*), A from T

we have now left the reservation.  

The OP may find SQLite's behavior in this regard unintuitive because it
is illogical.  Consider this table, 

sqlite> select * from T;
A 
--
1 
2 

IIRC Sybase 20 years ago would accept the above query and produce

select count(*), A from T;
count(*)A 
--  --
2   1 
2   2 

which makes a little sense: here are the values of A you asked for, and
the count of T you asked for.  In modern terms, 

select A, q from T 
cross join (select count(*) as q from A) as Q

But SQLite sort of punts, 

sqlite> select count(*), A from T;
count(*)A 
--  --
2   2 

i.e., here's an arbitrary value of A and the count of T.  It doesn't
make sense because it doesn't make sense.  

I'm sure there are applications that depend on the current, documented
behavior.  I'm equally sure there's a constituency that would favor
either standard behavior or (better) making GROUP BY optional and
producing an error only when it disagrees with SELECT.  Perhaps there
is room for that in version 4.  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] In-memory DB slower than disk-based?

[Jensen, Vern]

Hey all! We use SQLite (3.7.15.2) as the backend for a server that provides 
floating licenses for our software. I've recently written a stress-testing 
framework that starts up any number of threads, and hits the server with 
multiple requests per thread.
While being stress-tested in this way, I've found that if the testing framework 
is using 100 threads, a single call to sqlite3_exec() can take 8-15 seconds at 
times (assuming my timeout set with sqlite3_busy_timeout is big enough to allow 
this, otherwise is failed with error code 5 -- LOCKED). This is when doing DB 
writes, obviously. journal_mode is set to WAL.

I assumed that by switching from a DB file on disk to one in memory, we'd see 
this 'write' bottleneck nearly disappear. We don't have too many records in the 
tables being written to, so the only reasonable explanation for 8-15 seconds 
for some writes would be that the DB is on disk.

Yet when switching to an in-memory database (with a shared cache, since 
currently the server has 30 separate threads, each with their own separate 
SQLite connection), I found the performance actually got slightly *worse* than 
with a disk-based version. I re-ran the tests each way several times, and 
indeed, performance is worse.
I open the shared-cache in-memory DB like this:

int result = sqlite3_open_v2("file:memdb1?mode=memory=shared", &_db, 
flags, NULL);

I also tried using these for the in-memory version (versus WAL journaling mode):

sqlite3_exec(_db, "PRAGMA read_uncommitted=true", NULL, NULL, NULL);
sqlite3_exec(_db,"PRAGMA journal_mode=OFF",NULL,NULL,NULL);

but to no avail. Still worse performance than when the DB is on disk. Which 
makes little sense to me.

I realize SQLite was not designed to be accessed concurrently by 100 separate 
users, and this really is a stress-testing case that far exceeds our expected 
real-world usage. But at the same time, I'd like to get this running as 
optimally as possible, and it seems like 8-15 second writes is unreasonable for 
an in-memory database. (Not that 8-15 seconds is the average... but even the 
average is 3-5 seconds when 100 threads are stress-testing the server at once.)

-Vern
IMPORTANT WARNING: This message is intended for the use of the person or entity 
to which it is addressed and may contain information that is privileged and 
confidential, the disclosure of which is governed by applicable law. If the 
reader of this message is not the intended recipient, or the employee or agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this information is 
STRICTLY PROHIBITED. If you have received this message in error, please notify 
us immediately by calling (310) 423-6428 and destroy the related message. Thank 
You for your cooperation.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Views as Virtual Tables -- Command line vs. Called Interface

[Keith Medcalf]

>TERSE QUESTION
>Is the sqlite3_table_column_metadata() SQLite C API function also wrapped
>by the APSW Python Library?
>http://www.sqlite.org/capi3ref.html#sqlite3_table_column_metadata

I don't see it presently.

>Or is there another way to get the primary key without scraping the SQL
>(string) field in the SQLite3 master table?

http://www.sqlite.org/pragma.htm

See the following PRAGMA's for retrieving table/index/foreign key info.  They 
return data in standard table format and work notwithstanding the support of 
the API and should work just fine with any interface to the SQLite library 
(even from the command line tool):

PRAGMA table_info
PRAGMA index_list
PRAGMA index_info
PRAGMA foreign_key_List





___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Expected behaviour of COUNT with no GROUP BY?

[Zsbán Ambrus]

On 8/4/14, Mark Lawrence  wrote:
> I try to remember to define GROUP BY values when using aggregate
> functions (and I wish SQLite considered it an error otherwise) but I
> forget once and the result surprised me.
>
> It is expected behaviour that a row is returned in this situation even
> through the tables are empty?  Adding a "GROUP BY x.id" returned the
> expected empty set.

This is the behavior I expect from the documentation.

Specifically, the documentation for the SELECT statement at
"http://sqlite.org/lang_select.html; says

> If the SELECT statement is an aggregate query without a GROUP BY clause, then 
> each aggregate expression in the result-set is evaluated once across the 
> entire dataset. [...] Or, if the dataset contains zero rows, then each 
> non-aggregate expression is evaluated against a row consisting entirely of 
> NULL values.
>
> [...] An aggregate query without a GROUP BY clause always returns exactly one 
> row of data, even if there are zero rows of input data.

--
Ambrus
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Views as Virtual Tables -- Command line vs. Called Interface

[Jim Callahan]

Roger,
Sorry for unintended slights.
My haste and terseness may have confused matters.

Another long story (below), but if you are in a hurry, my question is:

TERSE QUESTION
Is the sqlite3_table_column_metadata() SQLite C API function also wrapped
by the APSW Python Library?
http://www.sqlite.org/capi3ref.html#sqlite3_table_column_metadata

Or is there another way to get the primary key without scraping the SQL
(string) field in the SQLite3 master table?

LONG STORY
I like Jessica Hamrick's Python dbtools library for  the final conversion
to the Python pandas library data structures. I have posted the necessary
changes to her blog:

I like it, but I need to import a VIEW from SQLite to Pandas (I want to
shield my users from scary SQL JOINS and just present them one flat table).
Underlying Python/SQLite libraries support SQL VIEWS (see SQLite mailing
list "Views as Virtual Tables -- Command line vs. Called Interface". So, in
your code, need to change cmd = "SELECT name FROM sqlite_master WHERE
type='table'"

to
cmd = "SELECT name FROM sqlite_master WHERE type IN ('table','view')"

SQLite VIEWs are read only (not update-able)
so also need error msg-s if type='view' in insert, update and delete.
I would do myself, but I just downloaded Git yesterday and am not yet
familiar with version control."
http://www.jesshamrick.com/2013/04/13/on-collecting-data/

I also noticed that Jessica Hamrick's dbtools was scraping the SQL (string)
column in the SQLite master table with regular expressions to obtain the
column names, column types and the primary key (to use in creating pandas
object). I pointed out that the Python APSW library has wrapped the SQLite3
C API functions (sqlite3_column_name & sqlite3_column_decltype) for the
column name and column type. But, I don't see how to get the primary key in
APSW. Is the sqlite3_table_column_metadata() SQLite C API function
http://www.sqlite.org/capi3ref.html#sqlite3_table_column_metadata
also wrapped by the APSW Python Library? I posted:

Also, you don't have to scrape the colnames and types with regular
expressions; there is an api for that.
In the APSW SQLite Python library, there is a cursor.getdescription()
method that:
"returns information about each column is a tuple of (column_name,
declared_column_type). The type is what was declared in the CREATE TABLE
statement - the value returned in the row will be whatever type you put in
for that row and column. (This is known as manifest typing which is also
the way that Python works. The variable a could contain an integer, and
then you could put a string in it. Other static languages such as C or
other SQL databases only let you put one type in - eg a could only contain
an integer or a string, but never both.)" The APW calls the SQLite C API
functions:
sqlite3_column_name
sqlite3_column_decltype

So, [with APSW] you [would be] are relying on SQLite3's native parsing and
not someone else's random regex or homebrew parser.
http://rogerbinns.github.io/apsw/cursor.html#cursor-class

BTW, open source, Notepad++, has nice syntax highlighting for Python.

I have an afternoon and evening full of meetings, but I will attempt this
fix myself tomorrow (Tuesday) morning.

Cheers.

Jim Callahan
Orlando, FL






On Sun, Aug 3, 2014 at 11:31 AM, Roger Binns  wrote:

> Disclosure:  I am the apsw author
>
>
> On 08/02/2014 10:19 AM, Jim Callahan wrote:
>
>> I got apsw to work, but it had a curious side-effect
>> -- it clobbered my IPython prompt (replaced prompt with smiley faces).
>>
>
> APSW certainly didn't do that.  It doesn't do anything - you have to make
> calls and get responses.
>
> If you use the APSW shell then it will use ANSI escape sequences to colour
> the output.  However this is only done if the output is a terminal, and can
> be turned off.  (That is the case for Linux & Mac. For Windows you also
> need to install colorama.)
>
>
>  For those who are interested.
>> 1. downloaded apsw -- does not work with Python's package manager pip
>> http://apidoc.apsw.googlecode.com/hg/download.html#source-and-binaries
>>
>
> APSW moved from googlecode a while back.  It is at:
>
>   https://github.com/rogerbinns/apsw
>
> This explains why:
>
>   http://www.rogerbinns.com/blog/moving-to-github.html
>
> APSW is actually now on pypi.  Someone else put it up there and it has no
> connection to me.  It is also extremely unlikely to install because it
> doesn't handle the SQLite dependency, nor have Windows binaries.
>
>
>  3. commented out "import apswrow" from suggested script (not found, not
>> needed)
>>
>
> That has no connection to APSW either.  It is written by someone else to
> turn rows returned from a tuple into also having the column names.
>
> Roger
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list

Re: [sqlite] Abnormal memory usage

[Keith Medcalf]

>important correction - the problem actually exists on w2k8 (NT 6.0)(64bit
>at least). The test application works as expected on w2k8 r2 (NT 6.1).

>I am going to research it further, but at this point it looks like MS
>Windows issue, rather than sqlite.

Compiler & runtime environment breakage is far more likely on Microsoft 
platforms than is breakage in the OS itself.  The Windows API has not changed 
significantly since OS/2 New Technology 2.0.

Are you running the "exact same fully statically linked executable" on all 
platforms?  This is the only thing that would determine the issue was in the OS 
itself, and not related to the compiler or its runtime environment, or the 
runtime environment distributed with the OS.

Dependencies on the subsystem runtime library (MSVCRT.DLL) or the OS core DLLs 
themselves are of course permissible.  Dependencies on compiler associated 
runtimes (anything else) are not.




___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Expected behaviour of COUNT with no GROUP BY?

[RSmith]

On 2014/08/04 18:27, Mark Lawrence wrote:

On Mon Aug 04, 2014 at 06:04:53PM +0200, RSmith wrote:
Yes it does, thanks. I guess I still find the combination of COUNT without a GROUP BY to be unintuitive, but at least I know why now. 


As far as I know, there is no requirement for a group by clause for any of the functions really, a table or any SELECT result set is 
by definition "a group" (or should I say "the Group"), and unless a "group by" is explicitly stated, the table/result-set is itself 
the group and all group functions (aggregates functions) should work on it. The reverse is not necessarily true though, in that SQL 
(the Standard anyway) really requires you to specify an aggregate function for each and every element in a SELECT containing a GROUP 
BY function - but most engines (SQLite too) are quite lenient in this regard.


(This being my current understanding and experience, I might be wrong)

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Expected behaviour of COUNT with no GROUP BY?

[Mark Lawrence]

On Mon Aug 04, 2014 at 06:04:53PM +0200, RSmith wrote:
> CREATE TABLE x(id INTEGER);
> 
> SELECT Count(*) FROM x;
> | 0 |
> 
> --vs.--
> SELECT Count(*) FROM x GROUP BY id;
> (No Results)
> 
> 
> Paints a clear picture I hope!

Yes it does, thanks. I guess I still find the combination of COUNT
without a GROUP BY to be unintuitive, but at least I know why now.

-- 
Mark Lawrence
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Abnormal memory usage

[smallstone193]

important correction - the problem actually exists on w2k8 (NT 6.0)(64bit at
least). The test application works as expected on w2k8 r2 (NT 6.1).

I am going to research it further, but at this point it looks like MS
Windows issue, rather than sqlite. 





___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Expected behaviour of COUNT with no GROUP BY?

[RSmith]

I'm not 100% sure if the devs had another reason for doing it this way , but the results are very much expected in normal SQL terms 
- simply because "count()" returns a value which is sensible and represents the actual number of items in the ungrouped list... the 
fact that the value returned is Zero has nothing to do with the concept, it still returns a value and as such forms part of a valid 
record line. If however you add the GROUP BY clause, then there is no valid group to return a count of... and hence no line.


You don't even need all those example DBs, can just do this:

CREATE TABLE x(id INTEGER);

SELECT Count(*) FROM x;
| 0 |

--vs.--
SELECT Count(*) FROM x GROUP BY id;
(No Results)


Paints a clear picture I hope!


On 2014/08/04 17:47, Mark Lawrence wrote:

I try to remember to define GROUP BY values when using aggregate
functions (and I wish SQLite considered it an error otherwise) but I
forget once and the result surprised me.

 CREATE TABLE x(
 id INTEGER
 );

 CREATE TABLE y(
 id INTEGER
 );

 SELECT
 x.id,
 count(y.id)
 FROM
 x
 INNER JOIN
 y
 ON
 y.id = x.id
 ORDER BY
 x.id
 ;

Result:

 id  count(y.id)
 --  ---
 NULL0

It is expected behaviour that a row is returned in this situation even
through the tables are empty?  Adding a "GROUP BY x.id" returned the
expected empty set.



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Expected behaviour of COUNT with no GROUP BY?

[Richard Hipp]

On Mon, Aug 4, 2014 at 11:47 AM, Mark Lawrence  wrote:

>
> It is expected behaviour that a row is returned in this situation even
> through the tables are empty?
>

Yes.  All SQL database engines work that way.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Expected behaviour of COUNT with no GROUP BY?

[Mark Lawrence]

I try to remember to define GROUP BY values when using aggregate
functions (and I wish SQLite considered it an error otherwise) but I
forget once and the result surprised me.

CREATE TABLE x(
id INTEGER
);

CREATE TABLE y(
id INTEGER
);

SELECT
x.id,
count(y.id)
FROM
x
INNER JOIN
y
ON
y.id = x.id
ORDER BY
x.id
;

Result:

id  count(y.id)
--  ---
NULL0  

It is expected behaviour that a row is returned in this situation even
through the tables are empty?  Adding a "GROUP BY x.id" returned the
expected empty set.

-- 
Mark Lawrence
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Producing RFC4180-compliant CSV output

[Edward Lau]

Hi Peter:


Specifically, if you are going to use SQL Server Integration Services (SSIS) 
you can specify LF as the record delimiter.  It defaults to {CR}{LF} but you 
can change it in the FlatFile Connection Manager under the Advance tab. 



-Original Message-
From: Peter Waller 
To: sqlite-users 
Cc: developers 
Sent: Thu, Jul 24, 2014 2:27 am
Subject: [sqlite] Producing RFC4180-compliant CSV output


Hi All,

We're using `sqlite -csv` to generate CSV files because it is the best
performing thing available to us. It turns out however that the CSV spec
demands CRLF line endings [1].

There is software in the wild that barfs on non-CRLF-line-ending files,
such as SQL Server Integration Services [2].

Currently as best as we can tell from inspecting the source the output
depends on the platform you run on, depending on what "text mode" means
there. On Linux and on Windows using the official binaries, that means you
get the wrong line endings (just 'plain' \n).

We have made a patch which works well in our environment which just makes
CSV output \r\n instead of just \n. On Windows using the same compiler as
the official binaries are built with the behaviour should be the same, but
it may produce different output if a different compiler is used, because
the behaviour of a file opened in text mode could vary.

Would a patch be accepted to change the line endings to \r\n?

Thanks,

- Peter

[1] http://tools.ietf.org/html/rfc4180#section-2
[2] https://en.wikipedia.org/wiki/SQL_Server_Integration_Services
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] parser stack overflow in view

[Clemens Ladisch]

Michael wrote:
>> Von: "Richard Hipp" 
>> The LALR(1) parser stack is limited to a depth of 100, by default.
>
> Ok thanks. I reduced it by one subquery to be conform with standard builds.

The parser has different limits than the SQL execution engine.
You could simply move some part(s) of the query into a (temporary) view.


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？

[Andy Ling]

> -Original Message-
> 
> 2014-08-02 16:00 GMT+02:00 王庆刚 <2004wqg2...@163.com>:
> > hi ， Can Sqlite3.c and sqlite.h be compiled in Workbench3.2 for
> Vxworks6.8 ?
> > When I  compile them , there have so many problems .
> > ___
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> You can find the necessary changes here:
>  scm.org/index.html/vpatch?from=dd5743a8239d1ce9=b68f65bb69a098a
> 1>
> thanks to Andy Ling.
> 

Yes, I build it in Workbench 3.3 and vxWorks 6.9 as part of a RTP. I use the 
compile flags

-DHAVE_UTIME -DSQLITE_OMIT_LOAD_EXTENSION

You can probably make the load extension work if you need it. It requires 
linking to the dynamic linking library.

Regards

Andy Ling


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] parser stack overflow in view

[Michael]

Ok thanks. I reduced it by one subquery to be conform with standard builds.

My querys are auto generated and are not often needed to read by human.
For my porpose it was the only way build a correct structure for
searching hirarchy with needed options.
category/subcat1/subcat2/subcat3

Anyway. I have one problem left. If I do "select count(*) from (... 
UNION ALL ...   );" I still get stack overflow. Ok I know why but don't
know to avoid that.

Is there a better way to count the results of big query before?


> Gesendet: Freitag, 01. August 2014 um 13:41 Uhr
> Von: "Richard Hipp" 
> An: "General Discussion of SQLite Database" 
> Betreff: Re: [sqlite] parser stack overflow in view
>
> On Tue, Jul 29, 2014 at 5:00 AM, Michael 
wrote:
>
> > I have a view with about 6 Unions and a depth of about 6 subselects in
> > each select.
> > Shouldn't be a big thing and it was no problem with sqlite 3.7.17.
> > Since 3.8 (3.8.4.3) I get "parser stack overflow". I have many queries
> > with this problem now...
> >
>
>
> The LALR(1) parser stack is limited to a depth of 100, by default. 
You can
> change that at compile-time using -DYYSTACKDEPTH=nnn  where "nnn" is some
> number.  If you make "nnn" equal to zero, then the LALR(1) parser stack is
> obtained from sqlite3_realloc() and it can grow without bound.  In your
> particular case, you can get your query to run successfully by increasing
> the default stack size by just one to -DYYSTACKDEPTH=101.
>
> We have discussed making the stack unlimited depth by default.  But there
> is a small performance and size penalty for doing that.  And, honestly, if
> your query needs more than 100 levels of LALR(1) stack, it is going to be
> difficult for a human to read anyhow, and probably needs to be refactored.
> So I think we will keep the default 100-level limit for the time being and
> let individual applications extend the limit at compile-time, if they need
> to.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users