Re: [sqlite] Issue with sqlite3_uri_parameter

Actually, SQLite does use sqlite3_uri_parameter indirectly via sqlite3_uri_boolean, but I haven't been able to blow up sqlite3 by supplying malformed URIs.  I thing sqlite3ParseUri throws bad options away. On Thursday, July 3, 2014 3:20 PM, Peter Aronson wrote: > > >I

Re: [sqlite] Issue with sqlite3_uri_parameter

I believe the function expects URIs of the general form (before separators are converted to Nuls) of file:filename?param1=value1=v2 coverted into file nul param1 nul value1 ... which means that the argument to this function is always expected to have an odd number of strings.  Your input has an

[sqlite] Issue with sqlite3_uri_parameter

Hello, Using VFS and sqlite3_uri_parameter, it appears that it ends with an Access Violation. Looking a bit more closely to the code of this function: SQLITE_API const char *sqlite3_uri_parameter(const char *zFilename, const char *zParam){ if( zFilename==0 ) return 0; zFilename +=

Re: [sqlite] Sqlite in dead lock state when deleting records from the same table from different threads

Hi, But in shared cache mode. I assume this is going to be a table level lock, instead of a lock on the whole database. This will really block other threads which are dealing with other tables. http://www.sqlite.org/sharedcache.html 2.1 Transaction Level Locking SQLite connections can open

Re: [sqlite] Sqlite in dead lock state when deleting records from the same table from different threads

On 3 Jul 2014, at 6:11pm, Srikanth Bemineni wrote: > > As per Igor > BEGIN IMMEDIATE should get a write lock on the table 1 when first select > call is initiated > > 10:00.234 Thread 1 BEGIN > 10:00.235 Thread 1 select * from > 10:00.234 Thread 1 select * from >

Re: [sqlite] think I need better error-handling guidance in the C API

RSmith wrote: > I do hope your request is escalated to a ticket. Yet a third person who completely agrees with me in every way! :-) How 'bout it, SQLite devs? > You seem well-versed in these matters, I believe there is a need for a > documentation specialist in the sqlite dev team, apply

Re: [sqlite] Sqlite in dead lock state when deleting records from the same table from different threads

Hi, For some reason I was not getting any mails from the groups. At last Mike Owens was a able to resolve the issue. I did used to get the digest mails which contained the conversation with respect to this thread. Just to rephrase from what ever I understood till now As per Igor BEGIN IMMEDIATE

Re: [sqlite] think I need better error-handling guidance in the C API

On 2014/07/03 18:19, Eric Rubin-Smith wrote: The fact that (literally) millions of applications get written despite any perceived shortcomings in the documentation suggests that the docs are at least "adequate," if not "perfect." Your argument is analogous to an argument that the Earth is the

Re: [sqlite] Like and percent character

On 2014/07/03 17:58, Micka wrote: Sorry every one ! It's my fault ! I made a function on top of sqlite3_exec which have : va_start(argp,acSql); vasprintf(, acSql, argp); So this one tried to identify the %A . my bad ^^ All good :) This is why I was asking for your code in an

Re: [sqlite] think I need better error-handling guidance in the C API

Stephan Beal wrote: > While i do fundamentally agree with your points, in practice it's not > as difficult as you seem to be making it out to be. The rule is really > simple: any non-0 code is an error unless the APIs specify otherwise, > and the step() API does indeed document 2 non-error,

Re: [sqlite] Like and percent character

On 3 Jul 2014, at 4:58pm, Micka wrote: > my bad ^^ No problem. Glad you figured it out. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Like and percent character

Sorry every one ! It's my fault ! I made a function on top of sqlite3_exec which have : va_start(argp,acSql); vasprintf(, acSql, argp); So this one tried to identify the %A . my bad ^^ On Thu, Jul 3, 2014 at 5:40 PM, Simon Slavin wrote: > > > On 3 Jul 2014, at

Re: [sqlite] Like and percent character

> On 3 Jul 2014, at 2:38pm, RSmith wrote: > > > On 2014/07/03 15:12, Micka wrote: >> It's really weird that : >> >> SELECT * FROM names where name LIKE '%mic%' >> >> works with the sqlite3 command shell but not with the C librairie .. It works fine with the C

Re: [sqlite] 64-bit precompiled command-line shell binary

On 2014/07/03 16:52, Gert Van Assche wrote: I cannot test what RSmith wants to test, but I trust his expertise on this (SQLitespeed is a nice tool!) I don't mean to sound so official, but sometimes forget to add - the name is just Ryan :) I am not even sure if the tests are attainable -

Re: [sqlite] 64-bit precompiled command-line shell binary

Jan, for what I want to do, this exe is a perfect solution. It is working fine. I cannot test what RSmith wants to test, but I trust his expertise on this (SQLitespeed is a nice tool!) Thanks for your work on this, both of you. gert 2014-07-03 15:54 GMT+02:00 RSmith :

Re: [sqlite] think I need better error-handling guidance in the C API

On Thu, Jul 3, 2014 at 4:44 PM, Stephan Beal wrote: > non-error, non-0 error codes (SQLITE_STEP and SQLITE_DONE). Anywhere else > in the API, non-0 means Bad News. There > correction: SQLITE_ROW and SQLITE_DONE -- - stephan beal

Re: [sqlite] think I need better error-handling guidance in the C API

On Thu, Jul 3, 2014 at 4:27 PM, Eric Rubin-Smith wrote: > I respectfully re-raise my issue. The "TLDR" is that the C API docs are > critically lacking in specificity in a relatively wide range of areas, as > exemplified below, making it difficult to write correct clients

Re: [sqlite] think I need better error-handling guidance in the C API

I respectfully re-raise my issue. The "TLDR" is that the C API docs are critically lacking in specificity in a relatively wide range of areas, as exemplified below, making it difficult to write correct clients against the library. Do the SQLite authors disagree with my below points about the API

Re: [sqlite] 64-bit precompiled command-line shell binary

On 2014/07/03 13:55, Jan Nijtmans wrote: 2014-07-01 21:12 GMT+02:00 RSmith : I seem to remember a similar question having surfaced some time ago but cannot find the reference now - so let me ask the great forum devs again: WIll the 64-bit version of sqlite3.exe be able to

Re: [sqlite] Problem with many connections

On 2014/07/03 14:05, Simon Slavin wrote: On 3 Jul 2014, at 8:47am, Hick Gunter wrote: This function is already available in the sqlite3 C interface. I did not understand that at all. I have never needed to look at that statement. But yes, it does allow you to find out

Re: [sqlite] Like and percent character

On 2014/07/03 15:12, Micka wrote: It's really weird that : SELECT * FROM names where name LIKE '%mic%' works with the sqlite3 command shell but not with the C librairie .. Really? So if you simply make the string testSQL = "SELECT * FROM names WHERE name LIKE '%mic%';" and pass it

Re: [sqlite] Like and percent character

It's really weird that : SELECT * FROM names where name LIKE '%mic%' works with the sqlite3 command shell but not with the C librairie .. On Thu, Jul 3, 2014 at 2:19 PM, Micka wrote: > Well, > > I would love that to be simple . but when I printf my query, I

Re: [sqlite] Like and percent character

Well, I would love that to be simple . but when I printf my query, I got : SELECT * FROM names where name LIKE '%mic%' that the code : sprintf( acQuery, "SELECT * FROM names where name LIKE '%%%s%%' ", acName); So what could it be ? any ideas ? On Tue, Jun 3, 2014 at 4:21 PM, Hick

Re: [sqlite] Problem with many connections

On 3 Jul 2014, at 8:47am, Hick Gunter wrote: > This function is already available in the sqlite3 C interface. I did not understand that at all. I have never needed to look at that statement. But yes, it does allow you to find out if there are any open statements for a

Re: [sqlite] 64-bit precompiled command-line shell binary

Thanks Jan. I'll test it this afternoon. gert 2014-07-03 13:55 GMT+02:00 Jan Nijtmans : > 2014-07-01 21:12 GMT+02:00 RSmith : > > I seem to remember a similar question having surfaced some time ago but > > cannot find the reference now - so let me

Re: [sqlite] 64-bit precompiled command-line shell binary

2014-07-01 21:12 GMT+02:00 RSmith : > I seem to remember a similar question having surfaced some time ago but > cannot find the reference now - so let me ask the great forum devs again: > WIll the 64-bit version of sqlite3.exe be able to use >2GB of memory for > itself Really

Re: [sqlite] evaluate expression stored in a column

On Thu, Jul 3, 2014 at 7:19 AM, Hick Gunter wrote: > Not possible in SQL. "b.answer || a.epxr" is a string. It does not get > evaluated. Unless you write your own eval() function that executes its > parameter as an SQL statement, which is going to be very slow as each > result

Re: [sqlite] evaluate expression stored in a column

Not possible in SQL. "b.answer || a.epxr" is a string. It does not get evaluated. Unless you write your own eval() function that executes its parameter as an SQL statement, which is going to be very slow as each result row needs to prepare, step and finalize its very own statement.

[sqlite] a few documentation bugs

Hi all, Thanks for sqlite. I noticed a couple of documentation bugs. In compile.html: -DSQLITE_DISABLE_FTS3_UNICODE is documented but obsolete -DSQLITE_ENABLE_FTS4_UNICODE61 is not documented In vtab.html - typo "must should" in "The xCreate must should return SQLITE_OK if ..."

[sqlite] evaluate expression stored in a column

Hello all I have the following requirement: Table a id int expr text result integer Insert into a values (10,' > 2'); Table b --- id int answer text Insert into b values (10,'10'); I need to evaluate the condition that 10 > 2 and store the result of that expression in

Re: [sqlite] Problem with many connections

On Wed, 02 Jul 2014 17:03:43 +0100, Grzegorz Sikorski wrote: > Hi Hick, > > You were right I was not finalizing statements and this prevented close > to complete. When I modified my code to finalize all statements before > close it works fine. > > However I was always

Re: [sqlite] Problem with many connections

This function is already available in the sqlite3 C interface. It would be quite easy to implement a virtual table prepared_statements ( db int hidden, stmt int, sql text) to allow "select * from prepared_statements where db = ?" and bind your db handle. xBestIndex would need to check for

Re: [sqlite] Problem with many connections

On 3 Jul 2014, at 8:24am, Hick Gunter wrote: > How about this? > > > sqlite3_stmt *sqlite3_next_stmt(sqlite3 *pDb, sqlite3_stmt *pStmt); > > This interface returns a pointer to the next prepared statement after pStmt > associated with the database connection pDb. If pStmt

Re: [sqlite] Problem with many connections

How about this? sqlite3_stmt *sqlite3_next_stmt(sqlite3 *pDb, sqlite3_stmt *pStmt); This interface returns a pointer to the next prepared statement after pStmt associated with the database connection pDb. If pStmt is NULL then this interface returns a pointer to the first prepared statement