Re: [sqlite] Benign SQLITE_SCHEMA error?

On Mon, Jun 9, 2014 at 9:45 PM, Ward Willats wrote: > Hello. > > Running Sqlite 3.8.4.3 in an iOS application in WAL mode. One writer. Many > readers. Each thread on own connection. > > After a particular big bulk insert of data, during which, BTW, indices are > dropped

[sqlite] Benign SQLITE_SCHEMA error?

Hello. Running Sqlite 3.8.4.3 in an iOS application in WAL mode. One writer. Many readers. Each thread on own connection. After a particular big bulk insert of data, during which, BTW, indices are dropped and recreated and an ANALYZE done, sqlite is reporting on the SQLITE_CONFIG_LOG

[sqlite] SQLITE_PROTOCOL errors (was: Re: SQLite version 3.8.5 beta)

> On Tue, 27 May 2014 06:40:08 -0400, Richard Hipp said: > Nothing has changed with SQLITE_PROTOCOL since 3.7.6. > In big bold letters at the top of the ticket entry form, it says: "Tickets > for issues that have not been previously discussed on the mailing list will > usually

Re: [sqlite] Bug in nonassoc handling with Lemon parser generator

On Sun, Jun 8, 2014 at 10:52 AM, Alexander Barrentine < alexander.barrent...@gmail.com> wrote: > I can’t tell just now if this is the right place to be sending bug reports > for Lemon. I have identified a failing in the handling of nonassoc > precedence with the generated grammars. > Thanks.

Re: [sqlite] PRAGMA table_info(table-name); - column index reliable?

On Mon, Jun 9, 2014 at 7:06 AM, David Q. wrote: > > D. Richard Hipp: > > No. For a multi-column primary key, the columns that are part of the > > primary key are numbered 1, 2, 3, 4, etc, according to which column they > > are in the primary key. > > For single-column

Re: [sqlite] PRAGMA table_info(table-name); - column index reliable?

> D. Richard Hipp: > No. For a multi-column primary key, the columns that are part of the > primary key are numbered 1, 2, 3, 4, etc, according to which column they > are in the primary key. > For single-column primary keys, they value will always be 1, yes. You're talking about a different

Re: [sqlite] PRAGMA table_info(table-name); - column index reliable?

David Q. wrote: > I get columns names in a table by executing the query > > pragma table_info('the_table_name'); > > and using > > sqlite3_column_text(,1) //index 1 = name > > for each row in the result set. > > This works, but can I rely on the index being 1 for the 'name' column? It's very

Re: [sqlite] Bug Report: Case Sensitive Like

On Fri, Jun 6, 2014 at 5:26 PM, Martin Abel wrote: > > select Name from Targets where Name like '%üabc%'; -- real UTF-8 chars "ü" > or alternatively > select Name from Targets where Name like '%üabc%'; -- real UTF-8 chars, > ASCII encoded as "ü" > > it does not work -

Re: [sqlite] BUG with unnecessary brackets in queries with IN ( SELECT .. )

On Sun, Jun 8, 2014 at 7:52 PM, Martin Hristov wrote: > Simple example : > > Working (correct result) > select id from tbl where id in (select id from tbl) > > NOT working (incorrect result) : > select id from tbl where id in ( ( select id from tbl) ) > In the first query,

Re: [sqlite] PRAGMA table_info(table-name); - column index reliable?

On Sat, Jun 7, 2014 at 5:16 AM, David Q. wrote: > I get columns names in a table by executing the query > > pragma table_info('the_table_name'); > > and using > > sqlite3_column_text(,1) //index 1 = name > > for each row in the result set. > > This works, but can I rely on

[sqlite] BUG with unnecessary brackets in queries with IN ( SELECT .. )

Simple example : Working (correct result) select id from tbl where id in (select id from tbl) NOT working (incorrect result) : select id from tbl where id in ( ( select id from tbl) ) ___ sqlite-users mailing list sqlite-users@sqlite.org

[sqlite] PRAGMA table_info(table-name); - column index reliable?

I get columns names in a table by executing the query pragma table_info('the_table_name'); and using sqlite3_column_text(,1) //index 1 = name for each row in the result set. This works, but can I rely on the index being 1 for the 'name' column? I don't see this documented anywhere.

[sqlite] Bug in nonassoc handling with Lemon parser generator

I can’t tell just now if this is the right place to be sending bug reports for Lemon. I have identified a failing in the handling of nonassoc precedence with the generated grammars. I detailed my findings in this StackOverflow page: 

[sqlite] Bug Report: Case Sensitive Like

Hi, I'm using SqLite intensively and it works quite well - great and thank you! I'm using the newest version 3.8.500. I've set pragma encoding = "UTF-8"; pragma case_sensitive_like = FALSE; in order to search case insensitive - and - it works, almost. When running something like this: select