Re: [sqlite] Extending Porter Tokenizer

2016-07-09 Thread Abhinav Upadhyay 
On Fri, Jul 8, 2016 at 3:01 AM, Matthias-Christian Ott  wrote:
> On 2016-07-05 18:11, Abhinav Upadhyay wrote:
>> I'm wondering if it is possible to extend the functionality of the
>> porter tokenizer. I would like to use the functionality of the Porter
>> tokenizer but before stemming the token, I want to decide whether the
>> token should be stemmed or not.
>>
>> Do I need to copy the Porter tokenizer and modify it to suit my needs
>> or there is a better way, to minimize code duplication?
>
> The first argument of the Porter tokenizer is its parent tokenizer. The
> Porter tokenizer calls the parent tokenizer's xTokenize function with an
> xToken function that wraps the xToken function that was passed to the
> xTokenize function of the Porter tokenizer and stems the tokens passed
> to it. So create a custom tokenizer that extracts the original xToken
> function from the xToken member of its pCtx parameter:
>
> typedef struct PorterContext PorterContext;
> struct PorterContext {
>   void *pCtx;
>   int (*xToken)(void *pCtx, int tflags, const char *pToken, int nToken,
>   int iStart, int iEnd);
>   char *aBuf;
> };
>
> typedef struct CustomTokenizer CustomTokenizer;
> struct CustomTokenizer {
>   fts5_tokenizer tokenizer;
>   Fts5Tokenizer *pTokenizer;
> };
>
> typedef struct CustomContext CustomContext;
> struct CustomContext {
>   void *pCtx;
>   int (*xToken)(void *pCtx, int tflags, const char *pToken, int nToken,
>   int iStart, int iEnd);
> };
>
> int customToken(
>   void *pCtx,
>   int tflags,
>   const char *pToken,
>   int nToken,
>   int iStart,
>   int iEnd
> ){
>   CustomContext *c = (CustomContext*)pCtx;
>   PorterContext *p;
>
>   if( stem ){
> c->xToken(c->pCtx, tflags, pToken, nToken, iStart, iEnd);
>   }else{
> p = (PorterContext)c->pCtx;
> return p->xToken(p->pCtx, tflags, pToken, nToken, iStart, iEnd);
>   }
> }
>
> int customTokenize(
>   Fts5Tokenizer *pTokenizer,
>   void *pCtx,
>   int flags,
>   const char *pText,
>   int nText,
>   int (*xToken)(void *, int, const char *, int nToken, int iStart,
>   int iEnd)
> ){
>   CustomTokenizer *t = (CustomTokenizer)pTokenizer;
>   CustomContext sCtx;
>   sCtx.pCtx = pCtx;
>   sCtx.xToken = xToken;
>   return t->tokenizer.xTokenize(t->pTokenizer, (void*)&sCtx, flags,
>   pText, nText, customToken);
> }
>
> Note that you are accessing an internal struct and relying on
> implementation details and therefore have check whether the struct or
> any other relevant implementation details changed with every release.

Thanks for the detailed response. I think this would work but we are
currently using FTS4. The ability of calling a parent tokenizer is
really what I needed, but I don't think this is possible with FTS4?

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

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-09 Thread J Decker 
Okay if this should change, I would recommand a new standard for all
libraries;  and since standards are so important maybe make them know about
it too...

do ... ORG_DOMAIN_APPLICATION_LIBRARY_MODULE_SOURCE_INCLUDED

where each piece becomes unqiqe so there's no collision.  I'd expect
compilers these days would support more than 32 characters required by the
standard (goodbye Borland BCC 3.1).

#ifndef ORG_SQLITE_SQLITE_SQLITE_INCLUDED

and copY and paste one other time...
I mean what editor doesnt' support double click to mark a word (the above
is within the genaral defitition of a 'word' ) to copy and click somewhere
to paste?

I mean ; how many times have I had a symbol in a header that collided with
sqlite? or ffmpeg? or zlib? or... wait like never.

someone probably just never considered deprecation of reservation as a
'law' and at least demote to 'recommended practice' because some obscure
compiler somewhere would start failing?




On Sat, Jul 9, 2016 at 5:50 PM, dandl  wrote:

> > Obviously the standard is broken/incorrect or your interpretation of it
> is
> > broken/incorrect.
>
> No, and the standard was very carefully written to say this, and it's easy
> to find references to back up this interpretation if you care to look for
> them. Or ask a question on SO.
>
> > Most API headers do the same thing.
>
> Yes, this is quite a common breach of the standard. That doesn't make it
> right.
>
> > Even the standard library does it, in
> > most compilers.
>
> Almost universally I would say. That is the entire point: these identifiers
> are reserved 'for the implementation', that is for the standard library to
> use, and no-one else.
>
> > Not all of them add the trailing _, but several do.  Whether
> > and particular one does or not seems to depend on whether the entropy of
> the
> > multiverse was odd or even at the time the API was generated.
>
> Irrelevant. The use of leading underscore followed by upper-case letter is
> in violation of the C standard S 7.1.3. And the standard has been unchanged
> since its first release, which is well before Sqlite was even thought of.
>
> Regards
> David M Bennett FACS
>
> Andl - A New Database Language - andl.org
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-09 Thread dandl 
> Obviously the standard is broken/incorrect or your interpretation of it is
> broken/incorrect.

No, and the standard was very carefully written to say this, and it's easy
to find references to back up this interpretation if you care to look for
them. Or ask a question on SO.

> Most API headers do the same thing.  

Yes, this is quite a common breach of the standard. That doesn't make it
right.

> Even the standard library does it, in
> most compilers.  

Almost universally I would say. That is the entire point: these identifiers
are reserved 'for the implementation', that is for the standard library to
use, and no-one else.

> Not all of them add the trailing _, but several do.  Whether
> and particular one does or not seems to depend on whether the entropy of
the
> multiverse was odd or even at the time the API was generated.

Irrelevant. The use of leading underscore followed by upper-case letter is
in violation of the C standard S 7.1.3. And the standard has been unchanged
since its first release, which is well before Sqlite was even thought of. 

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org


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

Re: [sqlite] Database is locked

2016-07-09 Thread Igor Korot 
Simon,

On Sat, Jul 9, 2016 at 7:09 PM, Simon Slavin  wrote:
>
> On 10 Jul 2016, at 12:06am, Igor Korot  wrote:
>
>> I'm trying to write some software in C{++}. Everything works fine except
>> when I exit the program exit I get the error "Database is locked".
>> I am only trying to retrieve the information about the database (queries on
>> sqlite_master).
>
> What command are you executing when you get "Database is locked" in return ?

sqlite3_close();

>
> Have you terminated your query properly ?  Did you call sqlite_finalize() on 
> it ?  Did you get SQLITE_OK back from that call ?

Yes, everything is finalized. And no error on finalization is produced.
That's why I'm asking if there is a tool that can check what is open.

Thank you.

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

Re: [sqlite] Database is locked

2016-07-09 Thread Simon Slavin 

On 10 Jul 2016, at 12:06am, Igor Korot  wrote:

> I'm trying to write some software in C{++}. Everything works fine except
> when I exit the program exit I get the error "Database is locked".
> I am only trying to retrieve the information about the database (queries on
> sqlite_master).

What command are you executing when you get "Database is locked" in return ?

Have you terminated your query properly ?  Did you call sqlite_finalize() on it 
?  Did you get SQLITE_OK back from that call ?

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

[sqlite] Database is locked

2016-07-09 Thread Igor Korot 
Hi,
Here is my situation.

I'm trying to write some software in C{++}. Everything works fine except
when I exit the program exit I get the error "Database is locked".
I am only trying to retrieve the information about the database (queries on
sqlite_master).

So here are my questions:
1. When the database file is locked does this mean that there is a
byte set somewhere in the db header? Most likely no, but I just want
to confirm
2. If the answer is no - is there a tool which will help identify which handle
is not closed/released?

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

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-09 Thread J Decker 
On Fri, Jul 8, 2016 at 4:56 PM, Daniel Seither  wrote:

> Using clang 3.8 with -Wreserved-id-macro (enabled by -Weverything), I
> just noticed that SQLite uses include guards with a leading underscore,
> for example _SQLITE3_H_ in the amalgamation. According to the C
> standard, this is a reserved identifier, leading to undefined behavior:
>
> > All identifiers that begin with an underscore and either an uppercase
> > letter or another underscore are always reserved for any use. [...]
> > If the program declares or defines an identifier in a context in
> > which it is reserved (other than as allowed by 7.1.4), or defines a
> > reserved identifier as a macro name, the behavior is undefined.
>
> sqlite isn't a program :) it's a library.



> (Source: the C11 standard, Section 7.1.3, see [1] for the latest draft
> of C11 before publication, which should be identical to the finished text)
>
> I guess that means that the include guards should be changed to no
> longer use leading underscores. Any opinions on that?
>
>
That has been in the standard since K&R.
http://stackoverflow.com/questions/22027252/what-define-identifiers-are-reserved-to-the-preprocessor
"

(C99, 7.1.3.p1) "All identifiers that begin with an underscore and either
an uppercase letter or another underscore are always reserved for any use."

Now regarding K&R book 2nd edition it is written:

(K&R 2nd edition, 2.1) "Don't begin variable names with underscore,
however, since library routines often use such names."

And if CRM actually refers to CARM (C A Reference Manual by Harbison &
Steele):

(CARM 5th edition, 10.1.1 Reserved Library Identifiers): "The identifiers
that are reserved for C implementations to use include: [...] for macros,
keywords, or global variables, identifiers beginning with _ and and either
a second _ or an uppercase letter (except _ _ STDC_...)"




http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier

could make it _sQLITE3_H




> Daniel
>
> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-09 Thread Doug Currie 
On Sat, Jul 9, 2016 at 12:05 PM, Keith Medcalf  wrote:

>
> [...] Most API headers do the same thing.  Even the standard library does
> it, in most compilers.  [...]


Sure, that's why they're reserved! So user code and the C compiler's
library implementation don't clash. The C standard reserves those
identifiers for itself (or future versions of itself) to use.

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

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-09 Thread Keith Medcalf 

Obviously the standard is broken/incorrect or your interpretation of it is 
broken/incorrect.

Most API headers do the same thing.  Even the standard library does it, in most 
compilers.  Not all of them add the trailing _, but several do.  Whether and 
particular one does or not seems to depend on whether the entropy of the 
multiverse was odd or even at the time the API was generated.

> -Original Message-
> From: sqlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users-
> boun...@mailinglists.sqlite.org] On Behalf Of Daniel Seither
> Sent: Friday, 8 July, 2016 17:56
> To: sqlite-users@mailinglists.sqlite.org
> Subject: [sqlite] Bug: SQLite's include guards are reserved identifiers
> 
> Using clang 3.8 with -Wreserved-id-macro (enabled by -Weverything), I
> just noticed that SQLite uses include guards with a leading underscore,
> for example _SQLITE3_H_ in the amalgamation. According to the C
> standard, this is a reserved identifier, leading to undefined behavior:
> 
> > All identifiers that begin with an underscore and either an uppercase
> > letter or another underscore are always reserved for any use. [...]
> > If the program declares or defines an identifier in a context in
> > which it is reserved (other than as allowed by 7.1.4), or defines a
> > reserved identifier as a macro name, the behavior is undefined.
> 
> (Source: the C11 standard, Section 7.1.3, see [1] for the latest draft
> of C11 before publication, which should be identical to the finished text)
> 
> I guess that means that the include guards should be changed to no
> longer use leading underscores. Any opinions on that?
> 
> Daniel
> 
> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



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

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-09 Thread dandl 
> Using clang 3.8 with -Wreserved-id-macro (enabled by -Weverything), I just
> noticed that SQLite uses include guards with a leading underscore, for
> example _SQLITE3_H_ in the amalgamation. According to the C standard, this
is
> a reserved identifier, leading to undefined behavior:
> 
> > All identifiers that begin with an underscore and either an uppercase
> > letter or another underscore are always reserved for any use. [...] If
> > the program declares or defines an identifier in a context in which it
> > is reserved (other than as allowed by 7.1.4), or defines a reserved
> > identifier as a macro name, the behavior is undefined.
> 
> (Source: the C11 standard, Section 7.1.3, see [1] for the latest draft of
C11
> before publication, which should be identical to the finished text)
> 
> I guess that means that the include guards should be changed to no longer
use
> leading underscores. Any opinions on that?

Yes, that's how I read it.

There are I believe two potential theoretical problems. 
1. An unusual but fully conforming compiler implementation could use an
identifier such as this for its own purposes; the behaviour in that case
would indeed be "undefined". Such an implementation could not be used "out
of the box" with Sqlite.

2. A fully conforming compiler implementation might treat the use of such an
identifier as a defect and issue a diagnostic. Although this would most
likely be at a warning level, such a compiler could not be used with Sqlite
in an environment where all warnings are automatically treated as errors.

The first of these is quite unlikely; the second is quite likely (and may be
the situation OP has encountered). Obviously there are workarounds in both
cases. 

Nevertheless I would tend to regard this as a bug.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org





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

Re: [sqlite] Lemon doesn't reset `yyerrcnt` after error

2016-07-09 Thread Nick Wellnhofer 

On 08/07/2016 21:54, Richard Hipp wrote:

Please try again with the latest version of Lemon.  Thanks.


This still doesn't work for me. I created a GitHub repo to demonstrate the 
problem:


https://github.com/nwellnhof/lemon-bug

Nick

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

Re: [sqlite] Lemon doesn't reset `yyerrcnt` after error

2016-07-09 Thread Nick Wellnhofer 

On 08/07/2016 21:54, Richard Hipp wrote:

Please try again with the latest version of Lemon.  Thanks.

On 7/6/16, Nick Wellnhofer  wrote:

On 05/07/2016 18:12, Richard Hipp wrote:

Please try https://www.sqlite.org/src/info/2683b375ad129117 and verify
that the changes on trunk are working.  Thanks.


Still doesn't work for me. The structure of the #ifdefs in `Parse` is:

 #ifdef YYERRORSYMBOL
   ...
 #elif defined(YYNOERRORRECOVERY)
   ...
 #else  /* YYERRORSYMBOL is not defined */
   ...
 #endif

Your first check-in modifies the first branch, your second check-in the
second
branch, resulting in:

 #ifdef YYERRORSYMBOL
   ...
   #ifndef YYNOERRORRECOVERY
 yypParser->yyerrcnt = -1;
   #endif
   ...
 #elif defined(YYNOERRORRECOVERY)
   ...
   #ifndef YYNOERRORRECOVERY
 yypParser->yyerrcnt = -1;
   #endif
   ...
 #else  /* YYERRORSYMBOL is not defined */
   ...
 #endif

The change to the second branch has no effect because YYNOERRORRECOVERY is
always defined. My patch modifies the third branch ("YYERRORSYMBOL is not
defined"). This fixes code that defines neither YYERRORSYMBOL nor
YYNOERRORRECOVERY. I think the code should look like this:

 #ifdef YYERRORSYMBOL
   ...
   #ifndef YYNOERRORRECOVERY
 yypParser->yyerrcnt = -1;
   #endif
   ...
 #elif defined(YYNOERRORRECOVERY)
   ...
 #else  /* YYERRORSYMBOL is not defined */
   ...
   yypParser->yyerrcnt = -1;
   ...
 #endif

(Another check for YYNOERRORRECOVERY isn't really needed in the third
branch.
It will always be undef.)

Nick








--
aevum GmbH
Nadistr. 12
80809 München
Germany

Tel: +49 89 35747589
http://aevum.de/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-09 Thread Daniel Seither 
Using clang 3.8 with -Wreserved-id-macro (enabled by -Weverything), I
just noticed that SQLite uses include guards with a leading underscore,
for example _SQLITE3_H_ in the amalgamation. According to the C
standard, this is a reserved identifier, leading to undefined behavior:

> All identifiers that begin with an underscore and either an uppercase
> letter or another underscore are always reserved for any use. [...]
> If the program declares or defines an identifier in a context in
> which it is reserved (other than as allowed by 7.1.4), or defines a
> reserved identifier as a macro name, the behavior is undefined.

(Source: the C11 standard, Section 7.1.3, see [1] for the latest draft
of C11 before publication, which should be identical to the finished text)

I guess that means that the include guards should be changed to no
longer use leading underscores. Any opinions on that?

Daniel

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

2016-07-09 Thread Olivier Mascia 
> Le 9 juil. 2016 à 12:33, Simon Slavin  a écrit :
> 
>> I'm really interested in knowing wether you use the engine in SERIALIZED or 
>> MULTITHREADED mode during this event reproduction?
> 
> In other words, please read the last part of
> 
> 
> 
> and try to reproduce your problem in "Multi-thread" mode.  If the problem 
> still occurs, please try again in "Serialized" mode.

In between I had a quick look at sqlite3.c code.  It looks like the source of 
the issue is expected. The MULTITHREADED mode relaxes usage of mutexes, albeit 
only on connections and statements structures.  The remaining bits of the 
engine still make uses of multiple mutexes to protect its integrity from 
multiple threads using the engine.

See sqlite3BtreeOpen() and this section of code where the 
SQLITE_MUTEX_STATIC_OPEN is acquired.
The SERIALIZED and MULTITHREADED modes both have SQLITE_THREADSAFE != 0 (which 
is right).

#if !defined(SQLITE_OMIT_SHARED_CACHE) && !defined(SQLITE_OMIT_DISKIO)
  /*
  ** If this Btree is a candidate for shared cache, try to find an
  ** existing BtShared object that we can share with
  */
  if( isTempDb==0 && (isMemdb==0 || (vfsFlags&SQLITE_OPEN_URI)!=0) ){
if( vfsFlags & SQLITE_OPEN_SHAREDCACHE ){
  int nFilename = sqlite3Strlen30(zFilename)+1;
  int nFullPathname = pVfs->mxPathname+1;
  char *zFullPathname = sqlite3Malloc(MAX(nFullPathname,nFilename));
  MUTEX_LOGIC( sqlite3_mutex *mutexShared; )

  p->sharable = 1;
  if( !zFullPathname ){
sqlite3_free(p);
return SQLITE_NOMEM_BKPT;
  }
  if( isMemdb ){
memcpy(zFullPathname, zFilename, nFilename);
  }else{
rc = sqlite3OsFullPathname(pVfs, zFilename,
   nFullPathname, zFullPathname);
if( rc ){
  sqlite3_free(zFullPathname);
  sqlite3_free(p);
  return rc;
}
  }
#if SQLITE_THREADSAFE
  mutexOpen = sqlite3MutexAlloc(SQLITE_MUTEX_STATIC_OPEN);
  sqlite3_mutex_enter(mutexOpen);
  mutexShared = sqlite3MutexAlloc(SQLITE_MUTEX_STATIC_MASTER);
  sqlite3_mutex_enter(mutexShared);
#endif

The whole issue then revolves around the SHARED_CACHE/PRIVATE_CACHE and not the 
SERIALIZED/MULTITHREADED mode. Chances are that if OP Brian tries the same 
scenario with PRIVATE_CACHE connections, the issue will not occur.

I think this would probably qualify for an inherent limitation, which might be 
documented, but not something necessarily undesirable.

-- 
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om



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

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

2016-07-09 Thread Simon Slavin 

On 9 Jul 2016, at 9:27am, Olivier Mascia  wrote:

> I'm really interested in knowing wether you use the engine in SERIALIZED or 
> MULTITHREADED mode during this event reproduction?

In other words, please read the last part of



and try to reproduce your problem in "Multi-thread" mode.  If the problem still 
occurs, please try again in "Serialized" mode.

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

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

2016-07-09 Thread Olivier Mascia 
> Le 9 juil. 2016 à 00:55, Brian Vincent  a écrit :
> 
> I've managed to reproduce a scenario where one database, database1.db is
> rebuilding a large wal-index.  Meanwhile, all other threads attempting to
> open completely unrelated databases (e.g. database2.db) are blocked until
> the wal-index on database1.db is finished rebuilding.  This is obviously
> undesirable.

It probably is.  *I* can't comment or recommend anything on what you described 
but I'm really interested in knowing wether you use the engine in SERIALIZED or 
MULTITHREADED mode during this event reproduction? And assuming it is the 
default mode SERIALIZED which is used, wether it is different when run in 
MULTITHREADED mode (in which the engine code is supposed to do much less 
contention between threads, in exchange for the app responsibility not to share 
any connection (and dependent structures like statements) between threads.

-- 
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om



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