Re: [sqlite] Multi-threading Common Problem

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/12/2011 01:26 PM, John Deal wrote:
> Good question.  Very possible my understanding is not complete.

This document has the full details:

  http://www.sqlite.org/lockingv3.html

>I have basically read and write transactions, each potentially with several 
>accesses to the DB.  
>I want to ensure that if a write transaction is happening, no read
transactions are in progress

You do know you can use transactions for reads?   Or use multiple database
connections to get isolation.  If you worry about the efficiency of the
latter then don't - ie get your code correct and then worry about
performance.  I recommend against the use of shared cache mode on general
purpose computers (as opposed to embedded devices with trivial amounts of
memory) because it changes some API behaviour (especially busy handling) and
the amount of memory "wasted" is a rounding error.

In any event it looks like I am not understanding some deeper aspect of what
you are doing.  My underlying point remains - there is absolutely no need to
remove or workaround SQLite's builtin mutexes.  They ensure that threaded
code does not screw things up and are thoroughly tested/developed.

Any question that starts with "so I removed/changed/subverted SQLite's
existing mutexes" will be followed with a response where you'll need to
prove that doing so isn't the cause.

It is ok to augment them with your own locking but even that should not be
necessary.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3MyPkACgkQmOOfHg372QTTXgCcCa2bDbYH9WKQ2J2fPYhKLHPX
DBgAoLoj+uRJ3GDIHWGU7TfgNXxDAuAH
=exlM
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Visual Studio EE 2010

[Don Ireland]

Thanks.  I'll give that a test in the morning and let you know the results.

Don Ireland

-Original Message-
From: "Afriza N. Arief" 
To: General Discussion of SQLite Database 
Sent: Thu, 12 May 2011 11:25 PM
Subject: Re: [sqlite] Visual Studio EE 2010

On Fri, May 13, 2011 at 10:10 AM, Don Ireland  wrote:

> I'm using C++/CLI & downloaded/installed the dotnet file at the link you
> provided.
>
> After doing so, I found several DLL files in two folders:  bin & GAD (I
> believe that's the name).
>
> Don Ireland
>
>
Hi,

Try creating a new C++/CLI Console project (
http://img24.imageshack.us/img24/316/cppcliproj.png ) and then paste the
code in the gist ( https://gist.github.com/969954 ).

You need the System.Data.SQLite.dll copied to the project folder.

warning: my first time writing C++/CLI code

Regards,

Afriza N. Arief
___
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] Visual Studio EE 2010

[Afriza N. Arief]

On Fri, May 13, 2011 at 10:10 AM, Don Ireland  wrote:

> I'm using C++/CLI & downloaded/installed the dotnet file at the link you
> provided.
>
> After doing so, I found several DLL files in two folders:  bin & GAD (I
> believe that's the name).
>
> Don Ireland
>
>
Hi,

Try creating a new C++/CLI Console project (
http://img24.imageshack.us/img24/316/cppcliproj.png ) and then paste the
code in the gist ( https://gist.github.com/969954 ).

You need the System.Data.SQLite.dll copied to the project folder.

warning: my first time writing C++/CLI code

Regards,

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

Re: [sqlite] Unhandled Exception: System.DllNotFoundException: Unable to load DLL 'SQLite.Interop.DLL

[Kevin Benson]

On Thu, May 12, 2011 at 7:56 PM, Jim O'Brien  wrote:



> I have installed sqlite-dotnet-x86-1007200 (using Full Install)
>
> I have a simple program to test System.Data.SQLite.
>
> It is compiled using 2008 C# Express (no ability to change target CPU) with
> all the proper references and usings.
>
> When I attempt to run it, I get the error "Unhandled Exception:
> System.DllNotFoundException: Unable to load DLL 'SQLite.Interop.DLL".
>
> Further, when I attempt to run test.exe from the install directory, I get a
> "bad format" exception which appears to relate to the Interop DLL.
>
> I am using WIndows Vista Home Premium SP2.
>
> BTW, my program runs just fine using the last release of the original
> System.Data.SQLite.
>
> Any thoughts?
>
> Regards,
> Jim
>
 Maybe this will get you going:

http://www.mail-archive.com/sqlite-users@sqlite.org/msg60673.html

--
   --
  --
 --ô¿ô--
K e V i N
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Can I dynamically select a table?

[Igor Tandetnik]

On 5/12/2011 10:20 PM, John wrote:
> These are the names of actual views in this example. Let me rename them:
>
>> insert into rules_table values (1, view10);
>> insert into rules_table values (2, view20);
>> insert into rules_table values (3, view30);
>> insert into rules_table values (4, view40);

These are not valid SQL. Perhaps you meant

insert into rules_table values (1, 'view10');

Anyway, you can do something like this:

select * from view10 where :condition_in = 1
union all
select * from view20 where :condition_in = 2
union all
select * from view30 where :condition_in = 3
union all
select * from view40 where :condition_in = 4;

-- 
Igor Tandetnik

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

Re: [sqlite] Can I dynamically select a table?

[John]

These are the names of actual views in this example. Let me rename them:

> insert into rules_table values (1, view10);
> insert into rules_table values (2, view20);
> insert into rules_table values (3, view30);
> insert into rules_table values (4, view40);

On Thu, May 12, 2011 at 7:45 AM, Igor Tandetnik  wrote:

> John  wrote:
> > I don't see how that helps. Let's say I have table with rules which
> > determine from which view to select:
> >
> > create rules_table
> > (condition integer, myview integer);
> >
> > insert into rules_table values (1,10);
> > insert into rules_table values (2,20);
> > insert into rules_table values (3,30);
> > insert into rules_table values (4,40);
> >
> > I would use this query to determine which view to use:
> >
> > select myview
> > from rules_table
> > where condition = :condition_in;
>
> I'm not sure I understand. What other tables do you have? How does an
> integer 10 (or 20, or 30, or 40) tell you which of these tables to use?
> --
> Igor Tandetnik
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



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

Re: [sqlite] Common Multi-treaded Problem

[Pavel Ivanov]

> Pavel, could you please specify what do you mean by "statements in this 
> transaction"? Statements
> that were prepared (sqlite3_prepare) or initiated (sqlite3_step) during the 
> transaction?

Statements that were initiated during the transaction.

> Also, is this something that one should immediately deduce, necessary 
> behavior based on the model
> of SQLite (or perhaps RDBMS, ACID), or is it something that one normally 
> learns by heart, being,
> for the end-user, just the way SQLite works?

Basic model for any transaction-based DBMS that support any
transaction isolation level stricter than "read uncommitted":
obtaining data for select statement cannot cross transaction boundary,
otherwise data would be inconsistent. But different DBMS can treat
this rule differently. SQLite fails to execute COMMIT if some
statements are active, Oracle cancels execution of all active
statements while executing COMMIT I believe. So it's some specifics
which should be learned by heart if one wants to work with DBMS
seriously.


Pavel


On Thu, May 12, 2011 at 9:53 PM, Mihai Militaru  wrote:
> If you don't mind, John, for bullying in the discussion...
>
> On Thu, 12 May 2011 17:58:40 -0400
> Pavel Ivanov  wrote:
>
>> There's no dependency between different prepared statements, but there
>> is dependency between transactions as they use the same database. And
>> transaction cannot be finished (implicitly or explicitly) until all
>> statements in this transaction are reset or finalized.
>
> Pavel, could you please specify what do you mean by "statements in this 
> transaction"? Statements
> that were prepared (sqlite3_prepare) or initiated (sqlite3_step) during the 
> transaction?
>
> Also, is this something that one should immediately deduce, necessary 
> behavior based on the model
> of SQLite (or perhaps RDBMS, ACID), or is it something that one normally 
> learns by heart, being,
> for the end-user, just the way SQLite works?
>
> Thanks,
> Mihai
>
> --
> Mihai Militaru 
> ___
> 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] Visual Studio EE 2010

[Don Ireland]

I'm using C++/CLI & downloaded/installed the dotnet file at the link you 
provided.  

After doing so, I found several DLL files in two folders:  bin & GAD (I believe 
that's the name).

Don Ireland

-Original Message-
From: "Afriza N. Arief" 
To: General Discussion of SQLite Database 
Sent: Thu, 12 May 2011 11:23 AM
Subject: Re: [sqlite] Visual Studio EE 2010

On Thu, May 12, 2011 at 11:18 PM, Don Ireland  wrote:

> I downloaded and installed sqlite-dotnet-x86-3070600.zip.
>
> But when I attempt to add it as preference in VSEE2010, I find several dll
> files.  But none of them results in me being able to include a SQLite.h
> file.
>
>
What kind of environment you are developing for? Are you doing .NET
development (as in C#, C++/CLI, etc) or native development in C/C++ ?

For C/C++, get the downloads from http://sqlite.org/download.html and for
.NET, get the downloads from
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki

It might be easier for .NET development to use the pre-compiled binaries.

Regards,

Afriza N. Arief
___
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] Common Multi-treaded Problem

[Mihai Militaru]

If you don't mind, John, for bullying in the discussion...

On Thu, 12 May 2011 17:58:40 -0400
Pavel Ivanov  wrote:

> There's no dependency between different prepared statements, but there
> is dependency between transactions as they use the same database. And
> transaction cannot be finished (implicitly or explicitly) until all
> statements in this transaction are reset or finalized.

Pavel, could you please specify what do you mean by "statements in this 
transaction"? Statements
that were prepared (sqlite3_prepare) or initiated (sqlite3_step) during the 
transaction?

Also, is this something that one should immediately deduce, necessary behavior 
based on the model
of SQLite (or perhaps RDBMS, ACID), or is it something that one normally learns 
by heart, being,
for the end-user, just the way SQLite works?

Thanks,
Mihai

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

Re: [sqlite] Common Multi-treaded Problem

[Pavel Ivanov]

> Humm.  Resetting each prepared statement right after use seemed to work.  So 
> in review, a select prepared statement will lock the DB from other threads 
> (or is it DB connections?) but not the current thread (or is it DB 
> connection).

Yes, you are right. Transactions and database locks are
per-connection. So if you work with only one connection (even sharing
it between different threads) and not resetting your statements it
means that all your application works in a one huge transaction,
committing everything at the end (I guess if you hard kill your
application in the middle you'll see that nothing was committed to the
database). And if you work with several different connections (no
matter in different threads or in a single thread) they will block
each other, i.e. if you execute writing transaction in one connection
you won't be able to write in a second connection and sometimes you
won't even able to read in a second connection.

And answering your question from another email: you can step through
any number of prepared statements simultaneously as long as they are
all created from the same connection. They won't block each other from
executing. You just can't call sqlite3_step() on one connection
simultaneously in several threads - they will be serialized. Other
than that you are free to step through any number of select statements
and execute updates in parallel. But there's one rule of thumb to
remember: never change data that should be returned in some active
select statement. You can get very surprising behavior in this case.


Pavel


On Thu, May 12, 2011 at 8:33 PM, John Deal  wrote:
> Hello Pavel,
>
> Humm.  Resetting each prepared statement right after use seemed to work.  So 
> in review, a select prepared statement will lock the DB from other threads 
> (or is it DB connections?) but not the current thread (or is it DB 
> connection).
>
> Thanks for the help!
>
> John
>
> --- On Thu, 5/12/11, Pavel Ivanov  wrote:
>
>> From: Pavel Ivanov 
>> Subject: Re: [sqlite] Common Multi-treaded Problem
>> To: "General Discussion of SQLite Database" 
>> Date: Thursday, May 12, 2011, 5:58 PM
>> > Interesting is the impression I
>> had with prepared statements was the reset was only
>> necessary if you wanted to reuse that statement.  Since
>> each each DB connection is in its own instance of a class
>> (with it own set of prepared statements) I would not think
>> there would be any dependency on different physical prepared
>> statements on different threads.  I would expect this with
>> incomplete transactions.
>>
>> There's no dependency between different prepared
>> statements, but there
>> is dependency between transactions as they use the same
>> database. And
>> transaction cannot be finished (implicitly or explicitly)
>> until all
>> statements in this transaction are reset or finalized.
>>
>>
>> Pavel
>>
>>
>> On Thu, May 12, 2011 at 4:01 PM, John Deal 
>> wrote:
>> > Hello Igor,
>> >
>> > That very well maybe it.  I am not at home so can't
>> test for sure but I reset the prepared statements right
>> before I use them so they are left hanging if another thread
>> came in.
>> >
>> > Interesting is the impression I had with prepared
>> statements was the reset was only necessary if you wanted to
>> reuse that statement.  Since each each DB connection is in
>> its own instance of a class (with it own set of prepared
>> statements) I would not think there would be any dependency
>> on different physical prepared statements on different
>> threads.  I would expect this with incomplete
>> transactions.
>> >
>> > Anyway, thanks for the insight.
>> >
>> > John
>> >
>> > --- On Thu, 5/12/11, Igor Tandetnik 
>> wrote:
>> >
>> >> From: Igor Tandetnik 
>> >> Subject: Re: [sqlite] Common Multi-treaded
>> Problem
>> >> To: sqlite-users@sqlite.org
>> >> Date: Thursday, May 12, 2011, 12:35 PM
>> >> On 5/12/2011 12:31 PM, John Deal
>> >> wrote:
>> >> > When I allow multiple readers with each
>> thread using a
>> >> different DB
>> >> > connection (open with the same flags) and
>> each thread
>> >> having
>> >> > exclusive use of its DB connection (no
>> sharing of
>> >> connections) and if
>> >> > more than one thread is reading the DB at the
>> same
>> >> time, the DB
>> >> > becomes locked for writing even when all the
>> reads are
>> >> finished.
>> >>
>> >> My first inclination would be to look for places
>> where you
>> >> leak active
>> >> statement handles, by failing to reset or
>> finalize
>> >> statements. The read
>> >> operation is not really finished until the
>> statement is
>> >> reset/finalized.
>> >> --
>> >> Igor Tandetnik
>> >>
>> >> ___
>> >> 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-use

Re: [sqlite] Common Multi-treaded Problem

[Simon Slavin]

On 13 May 2011, at 1:33am, John Deal wrote:

> Humm.  Resetting each prepared statement right after use seemed to work.  So 
> in review, a select prepared statement will lock the DB from other threads 
> (or is it DB connections?) but not the current thread (or is it DB 
> connection).

I don't think it's meant to work like that.  Are you getting errors when you 
call _finalize() ?



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

Re: [sqlite] Multi-threading Common Problem

[John Deal]

Hello Roger,

OK I see your point now.  I could most likely remove the OS mutexes.

Thanks,

John

--- On Thu, 5/12/11, Roger Binns  wrote:

> From: Roger Binns 
> Subject: Re: [sqlite] Multi-threading Common Problem
> To: sqlite-users@sqlite.org
> Date: Thursday, May 12, 2011, 4:01 PM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 05/12/2011 09:38 AM, John Deal wrote:
> > I have been working for weeks on this and I feel there
> must be something simple I am overlooking.  
> 
> Why are you discarding SQLite's builtin and tested mutexes
> and then
> effectively reimplementing your own to get the same
> effect?
> 
> Or bigger picture question what is it you are trying to
> achieve in the first
> place?
> 
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk3MPIkACgkQmOOfHg372QQzjgCg3106pWiiUMuOQay+2ONv3G0c
> ZvQAnAvBFXI+A8ae8tV9yXRmz7IZgid6
> =jehy
> -END PGP SIGNATURE-
> ___
> 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] Common Multi-treaded Problem

[John Deal]

Hello Pavel,

Humm.  Resetting each prepared statement right after use seemed to work.  So in 
review, a select prepared statement will lock the DB from other threads (or is 
it DB connections?) but not the current thread (or is it DB connection).

Thanks for the help!

John

--- On Thu, 5/12/11, Pavel Ivanov  wrote:

> From: Pavel Ivanov 
> Subject: Re: [sqlite] Common Multi-treaded Problem
> To: "General Discussion of SQLite Database" 
> Date: Thursday, May 12, 2011, 5:58 PM
> > Interesting is the impression I
> had with prepared statements was the reset was only
> necessary if you wanted to reuse that statement.  Since
> each each DB connection is in its own instance of a class
> (with it own set of prepared statements) I would not think
> there would be any dependency on different physical prepared
> statements on different threads.  I would expect this with
> incomplete transactions.
> 
> There's no dependency between different prepared
> statements, but there
> is dependency between transactions as they use the same
> database. And
> transaction cannot be finished (implicitly or explicitly)
> until all
> statements in this transaction are reset or finalized.
> 
> 
> Pavel
> 
> 
> On Thu, May 12, 2011 at 4:01 PM, John Deal 
> wrote:
> > Hello Igor,
> >
> > That very well maybe it.  I am not at home so can't
> test for sure but I reset the prepared statements right
> before I use them so they are left hanging if another thread
> came in.
> >
> > Interesting is the impression I had with prepared
> statements was the reset was only necessary if you wanted to
> reuse that statement.  Since each each DB connection is in
> its own instance of a class (with it own set of prepared
> statements) I would not think there would be any dependency
> on different physical prepared statements on different
> threads.  I would expect this with incomplete
> transactions.
> >
> > Anyway, thanks for the insight.
> >
> > John
> >
> > --- On Thu, 5/12/11, Igor Tandetnik 
> wrote:
> >
> >> From: Igor Tandetnik 
> >> Subject: Re: [sqlite] Common Multi-treaded
> Problem
> >> To: sqlite-users@sqlite.org
> >> Date: Thursday, May 12, 2011, 12:35 PM
> >> On 5/12/2011 12:31 PM, John Deal
> >> wrote:
> >> > When I allow multiple readers with each
> thread using a
> >> different DB
> >> > connection (open with the same flags) and
> each thread
> >> having
> >> > exclusive use of its DB connection (no
> sharing of
> >> connections) and if
> >> > more than one thread is reading the DB at the
> same
> >> time, the DB
> >> > becomes locked for writing even when all the
> reads are
> >> finished.
> >>
> >> My first inclination would be to look for places
> where you
> >> leak active
> >> statement handles, by failing to reset or
> finalize
> >> statements. The read
> >> operation is not really finished until the
> statement is
> >> reset/finalized.
> >> --
> >> Igor Tandetnik
> >>
> >> ___
> >> 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
> >
> ___
> 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

[sqlite] Unhandled Exception: System.DllNotFoundException: Unable to load DLL 'SQLite.Interop.DLL

[Jim O'Brien]

I have installed sqlite-dotnet-x86-1007200 (using Full Install)
 
I have a simple program to test System.Data.SQLite.
 
It is compiled using 2008 C# Express (no ability to change target CPU) with
all the proper references and usings.
 
When I attempt to run it, I get the error "Unhandled Exception:
System.DllNotFoundException: Unable to load DLL 'SQLite.Interop.DLL".
 
Further, when I attempt to run test.exe from the install directory, I get a
"bad format" exception which appears to relate to the Interop DLL.
 
I am using WIndows Vista Home Premium SP2.
 
BTW, my program runs just fine using the last release of the original
System.Data.SQLite.
 
Any thoughts?
 
Regards,
Jim
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Common Multi-treaded Problem

[John Deal]

Hello again Pavel,

OK but I am a bit confused.  What I have works as a single instance with one DB 
connection running under different threads as long as only one is using the DB 
connection at a time.  This is with prepared statements "hanging" (not reset) 
with different threads using different prepared statements (resetting the ones 
they use before using them).  With what you state this should not work (in this 
case both reads and writes work).

If I understand you correctly, on a single thread using one prepared statement 
(say a select) then using another prepared statement (say another select) 
should not work since the 1st prepared statement was not reset.  Also what 
about the time between the statement is executed (sqlite3_step()) and reading 
the return code and reading the retrieved data?  It is my understanding you 
can't reset the statement until after you have performed these activities. That 
would imply if what I interpret your statements correctly, that the database is 
locked until the reset is issued.

I appreacate your help.  I am just trying to understand what you are trying to 
tell me.

Thanks,

John 


--- On Thu, 5/12/11, Pavel Ivanov  wrote:

> From: Pavel Ivanov 
> Subject: Re: [sqlite] Common Multi-treaded Problem
> To: "General Discussion of SQLite Database" 
> Date: Thursday, May 12, 2011, 5:58 PM
> > Interesting is the impression I
> had with prepared statements was the reset was only
> necessary if you wanted to reuse that statement.  Since
> each each DB connection is in its own instance of a class
> (with it own set of prepared statements) I would not think
> there would be any dependency on different physical prepared
> statements on different threads.  I would expect this with
> incomplete transactions.
> 
> There's no dependency between different prepared
> statements, but there
> is dependency between transactions as they use the same
> database. And
> transaction cannot be finished (implicitly or explicitly)
> until all
> statements in this transaction are reset or finalized.
> 
> 
> Pavel
> 
> 
> On Thu, May 12, 2011 at 4:01 PM, John Deal 
> wrote:
> > Hello Igor,
> >
> > That very well maybe it.  I am not at home so can't
> test for sure but I reset the prepared statements right
> before I use them so they are left hanging if another thread
> came in.
> >
> > Interesting is the impression I had with prepared
> statements was the reset was only necessary if you wanted to
> reuse that statement.  Since each each DB connection is in
> its own instance of a class (with it own set of prepared
> statements) I would not think there would be any dependency
> on different physical prepared statements on different
> threads.  I would expect this with incomplete
> transactions.
> >
> > Anyway, thanks for the insight.
> >
> > John
> >
> > --- On Thu, 5/12/11, Igor Tandetnik 
> wrote:
> >
> >> From: Igor Tandetnik 
> >> Subject: Re: [sqlite] Common Multi-treaded
> Problem
> >> To: sqlite-users@sqlite.org
> >> Date: Thursday, May 12, 2011, 12:35 PM
> >> On 5/12/2011 12:31 PM, John Deal
> >> wrote:
> >> > When I allow multiple readers with each
> thread using a
> >> different DB
> >> > connection (open with the same flags) and
> each thread
> >> having
> >> > exclusive use of its DB connection (no
> sharing of
> >> connections) and if
> >> > more than one thread is reading the DB at the
> same
> >> time, the DB
> >> > becomes locked for writing even when all the
> reads are
> >> finished.
> >>
> >> My first inclination would be to look for places
> where you
> >> leak active
> >> statement handles, by failing to reset or
> finalize
> >> statements. The read
> >> operation is not really finished until the
> statement is
> >> reset/finalized.
> >> --
> >> Igor Tandetnik
> >>
> >> ___
> >> 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
> >
> ___
> 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] Multi-threading Common Problem

[John Deal]

Hello Pavel,

This makes sense but I have shared cache on.

Thanks.

--- On Thu, 5/12/11, Pavel Ivanov  wrote:

> From: Pavel Ivanov 
> Subject: Re: [sqlite] Multi-threading Common Problem
> To: "General Discussion of SQLite Database" 
> Date: Thursday, May 12, 2011, 5:55 PM
> > "After a BEGIN EXCLUSIVE, no
> other database connection except for read_uncommitted
> connections will be able to read the database and no other
> connection without exception will be able to write the
> database until the transaction is complete."
> >
> > This tells me that reads outside of a transaction
> would be permitted while an exclusive transaction is taking
> place.
> 
> This works only when shared cache mode is turned on and
> only within
> the same process. Nothing uncommitted can be read between
> processes or
> between different connections in the same process when
> shared cache is
> turned off.
> 
> 
> Pavel
> 
> 
> On Thu, May 12, 2011 at 4:26 PM, John Deal 
> wrote:
> > Good question.  Very possible my understanding is not
> complete.
> >
> > I have basically read and write transactions, each
> potentially with several accesses to the DB.  I want to
> ensure that if a write transaction is happening, no read
> transactions are in progress since it would be possible to
> have obtain incomplete data (mixture of some reads being
> valid but other no longer valid because the write
> transaction changed them).  In other words, a read
> "transaction" (I do not use a transaction for the reads)
> consists of multiple pieces of data that makeup a set that I
> want to ensure is valid as a set.
> >
> > It is my understanding that a transaction (which I do
> use for the write transaction which is also a set) locks the
> DB for writes but not reads. If a transaction does lock the
> DB for exclusive access then you are correct, I do not need
> the OS mutexes.  Maybe I do not understand the following:
> >
> > "After a BEGIN EXCLUSIVE, no other database connection
> except for read_uncommitted connections will be able to read
> the database and no other connection without exception will
> be able to write the database until the transaction is
> complete."
> >
> > This tells me that reads outside of a transaction
> would be permitted while an exclusive transaction is taking
> place.
> >
> > If a write transaction is not taking place, I want to
> allow multiple reads which the OS rwlock allows.
> >
> > Any enlightenment would be welcomed.
> >
> > Thanks.
> >
> > --- On Thu, 5/12/11, Roger Binns 
> wrote:
> >
> >> From: Roger Binns 
> >> Subject: Re: [sqlite] Multi-threading Common
> Problem
> >> To: sqlite-users@sqlite.org
> >> Date: Thursday, May 12, 2011, 4:01 PM
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 05/12/2011 09:38 AM, John Deal wrote:
> >> > I have been working for weeks on this and I
> feel there
> >> must be something simple I am overlooking.
> >>
> >> Why are you discarding SQLite's builtin and tested
> mutexes
> >> and then
> >> effectively reimplementing your own to get the
> same
> >> effect?
> >>
> >> Or bigger picture question what is it you are
> trying to
> >> achieve in the first
> >> place?
> >>
> >> Roger
> >> -BEGIN PGP SIGNATURE-
> >> Version: GnuPG v1.4.11 (GNU/Linux)
> >>
> >>
> iEYEARECAAYFAk3MPIkACgkQmOOfHg372QQzjgCg3106pWiiUMuOQay+2ONv3G0c
> >> ZvQAnAvBFXI+A8ae8tV9yXRmz7IZgid6
> >> =jehy
> >> -END PGP SIGNATURE-
> >> ___
> >> 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
> >
> ___
> 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] Common Multi-treaded Problem

[Pavel Ivanov]

> Interesting is the impression I had with prepared statements was the reset 
> was only necessary if you wanted to reuse that statement.  Since each each DB 
> connection is in its own instance of a class (with it own set of prepared 
> statements) I would not think there would be any dependency on different 
> physical prepared statements on different threads.  I would expect this with 
> incomplete transactions.

There's no dependency between different prepared statements, but there
is dependency between transactions as they use the same database. And
transaction cannot be finished (implicitly or explicitly) until all
statements in this transaction are reset or finalized.


Pavel


On Thu, May 12, 2011 at 4:01 PM, John Deal  wrote:
> Hello Igor,
>
> That very well maybe it.  I am not at home so can't test for sure but I reset 
> the prepared statements right before I use them so they are left hanging if 
> another thread came in.
>
> Interesting is the impression I had with prepared statements was the reset 
> was only necessary if you wanted to reuse that statement.  Since each each DB 
> connection is in its own instance of a class (with it own set of prepared 
> statements) I would not think there would be any dependency on different 
> physical prepared statements on different threads.  I would expect this with 
> incomplete transactions.
>
> Anyway, thanks for the insight.
>
> John
>
> --- On Thu, 5/12/11, Igor Tandetnik  wrote:
>
>> From: Igor Tandetnik 
>> Subject: Re: [sqlite] Common Multi-treaded Problem
>> To: sqlite-users@sqlite.org
>> Date: Thursday, May 12, 2011, 12:35 PM
>> On 5/12/2011 12:31 PM, John Deal
>> wrote:
>> > When I allow multiple readers with each thread using a
>> different DB
>> > connection (open with the same flags) and each thread
>> having
>> > exclusive use of its DB connection (no sharing of
>> connections) and if
>> > more than one thread is reading the DB at the same
>> time, the DB
>> > becomes locked for writing even when all the reads are
>> finished.
>>
>> My first inclination would be to look for places where you
>> leak active
>> statement handles, by failing to reset or finalize
>> statements. The read
>> operation is not really finished until the statement is
>> reset/finalized.
>> --
>> Igor Tandetnik
>>
>> ___
>> 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
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Multi-threading Common Problem

[Pavel Ivanov]

> "After a BEGIN EXCLUSIVE, no other database connection except for 
> read_uncommitted connections will be able to read the database and no other 
> connection without exception will be able to write the database until the 
> transaction is complete."
>
> This tells me that reads outside of a transaction would be permitted while an 
> exclusive transaction is taking place.

This works only when shared cache mode is turned on and only within
the same process. Nothing uncommitted can be read between processes or
between different connections in the same process when shared cache is
turned off.


Pavel


On Thu, May 12, 2011 at 4:26 PM, John Deal  wrote:
> Good question.  Very possible my understanding is not complete.
>
> I have basically read and write transactions, each potentially with several 
> accesses to the DB.  I want to ensure that if a write transaction is 
> happening, no read transactions are in progress since it would be possible to 
> have obtain incomplete data (mixture of some reads being valid but other no 
> longer valid because the write transaction changed them).  In other words, a 
> read "transaction" (I do not use a transaction for the reads) consists of 
> multiple pieces of data that makeup a set that I want to ensure is valid as a 
> set.
>
> It is my understanding that a transaction (which I do use for the write 
> transaction which is also a set) locks the DB for writes but not reads. If a 
> transaction does lock the DB for exclusive access then you are correct, I do 
> not need the OS mutexes.  Maybe I do not understand the following:
>
> "After a BEGIN EXCLUSIVE, no other database connection except for 
> read_uncommitted connections will be able to read the database and no other 
> connection without exception will be able to write the database until the 
> transaction is complete."
>
> This tells me that reads outside of a transaction would be permitted while an 
> exclusive transaction is taking place.
>
> If a write transaction is not taking place, I want to allow multiple reads 
> which the OS rwlock allows.
>
> Any enlightenment would be welcomed.
>
> Thanks.
>
> --- On Thu, 5/12/11, Roger Binns  wrote:
>
>> From: Roger Binns 
>> Subject: Re: [sqlite] Multi-threading Common Problem
>> To: sqlite-users@sqlite.org
>> Date: Thursday, May 12, 2011, 4:01 PM
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 05/12/2011 09:38 AM, John Deal wrote:
>> > I have been working for weeks on this and I feel there
>> must be something simple I am overlooking.
>>
>> Why are you discarding SQLite's builtin and tested mutexes
>> and then
>> effectively reimplementing your own to get the same
>> effect?
>>
>> Or bigger picture question what is it you are trying to
>> achieve in the first
>> place?
>>
>> Roger
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.11 (GNU/Linux)
>>
>> iEYEARECAAYFAk3MPIkACgkQmOOfHg372QQzjgCg3106pWiiUMuOQay+2ONv3G0c
>> ZvQAnAvBFXI+A8ae8tV9yXRmz7IZgid6
>> =jehy
>> -END PGP SIGNATURE-
>> ___
>> 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
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Multi-threading Common Problem

[John Deal]

Good question.  Very possible my understanding is not complete.

I have basically read and write transactions, each potentially with several 
accesses to the DB.  I want to ensure that if a write transaction is happening, 
no read transactions are in progress since it would be possible to have obtain 
incomplete data (mixture of some reads being valid but other no longer valid 
because the write transaction changed them).  In other words, a read 
"transaction" (I do not use a transaction for the reads) consists of multiple 
pieces of data that makeup a set that I want to ensure is valid as a set.

It is my understanding that a transaction (which I do use for the write 
transaction which is also a set) locks the DB for writes but not reads. If a 
transaction does lock the DB for exclusive access then you are correct, I do 
not need the OS mutexes.  Maybe I do not understand the following:

"After a BEGIN EXCLUSIVE, no other database connection except for 
read_uncommitted connections will be able to read the database and no other 
connection without exception will be able to write the database until the 
transaction is complete."

This tells me that reads outside of a transaction would be permitted while an 
exclusive transaction is taking place.

If a write transaction is not taking place, I want to allow multiple reads 
which the OS rwlock allows.

Any enlightenment would be welcomed.

Thanks.

--- On Thu, 5/12/11, Roger Binns  wrote:

> From: Roger Binns 
> Subject: Re: [sqlite] Multi-threading Common Problem
> To: sqlite-users@sqlite.org
> Date: Thursday, May 12, 2011, 4:01 PM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 05/12/2011 09:38 AM, John Deal wrote:
> > I have been working for weeks on this and I feel there
> must be something simple I am overlooking.  
> 
> Why are you discarding SQLite's builtin and tested mutexes
> and then
> effectively reimplementing your own to get the same
> effect?
> 
> Or bigger picture question what is it you are trying to
> achieve in the first
> place?
> 
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk3MPIkACgkQmOOfHg372QQzjgCg3106pWiiUMuOQay+2ONv3G0c
> ZvQAnAvBFXI+A8ae8tV9yXRmz7IZgid6
> =jehy
> -END PGP SIGNATURE-
> ___
> 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] fts virtual table questions

[Richard Hipp]

On Thu, May 12, 2011 at 4:07 PM, Paul Shaffer wrote:

> I didn't get an answer to my earlier question on fts. I guess it's
> difficult area.
>
> Should an fts virtual table always be re-created from scratch when the
> database is opened by the application before you start using fts commands?
>

No. FTS tables persist just like any other table.



> I see that the fts tables are not deleted when the database is closed. I
> have not found enough info on sqlite virtual tables generally.
>
> Do you find it is possible to incrementally add and delete rows in the fts
> virtual table (insert rows) as the application runs?


Yes.  That works fine for most users.



> As new data is added I
> would like to update the fts.
>
> If I delete rows in a table that was originally the source of data for fts
> virtual table creation, the fts virtual table retains all the expired data.
> In this case do you drop the fts table and recreate it, or try to delete
> rows in the fts table?
>

Just delete the rows in the FTS table.


>
> I would gladly get all this info from docs and not bother you, but the docs
> on sqlite fts don't have much practical everyday usage information.
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
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] fts virtual table questions

[Paul Shaffer]

I didn't get an answer to my earlier question on fts. I guess it's
difficult area.

Should an fts virtual table always be re-created from scratch when the
database is opened by the application before you start using fts commands?
I see that the fts tables are not deleted when the database is closed. I
have not found enough info on sqlite virtual tables generally.

Do you find it is possible to incrementally add and delete rows in the fts
virtual table (insert rows) as the application runs? As new data is added I
would like to update the fts.

If I delete rows in a table that was originally the source of data for fts
virtual table creation, the fts virtual table retains all the expired data.
In this case do you drop the fts table and recreate it, or try to delete
rows in the fts table?

I would gladly get all this info from docs and not bother you, but the docs
on sqlite fts don't have much practical everyday usage information.


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

Re: [sqlite] Common Multi-treaded Problem

[John Deal]

Hello Igor,

That very well maybe it.  I am not at home so can't test for sure but I reset 
the prepared statements right before I use them so they are left hanging if 
another thread came in.

Interesting is the impression I had with prepared statements was the reset was 
only necessary if you wanted to reuse that statement.  Since each each DB 
connection is in its own instance of a class (with it own set of prepared 
statements) I would not think there would be any dependency on different 
physical prepared statements on different threads.  I would expect this with 
incomplete transactions.

Anyway, thanks for the insight.

John

--- On Thu, 5/12/11, Igor Tandetnik  wrote:

> From: Igor Tandetnik 
> Subject: Re: [sqlite] Common Multi-treaded Problem
> To: sqlite-users@sqlite.org
> Date: Thursday, May 12, 2011, 12:35 PM
> On 5/12/2011 12:31 PM, John Deal
> wrote:
> > When I allow multiple readers with each thread using a
> different DB
> > connection (open with the same flags) and each thread
> having
> > exclusive use of its DB connection (no sharing of
> connections) and if
> > more than one thread is reading the DB at the same
> time, the DB
> > becomes locked for writing even when all the reads are
> finished.
> 
> My first inclination would be to look for places where you
> leak active 
> statement handles, by failing to reset or finalize
> statements. The read 
> operation is not really finished until the statement is
> reset/finalized.
> -- 
> Igor Tandetnik
> 
> ___
> 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] Multi-threading Common Problem

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/12/2011 09:38 AM, John Deal wrote:
> I have been working for weeks on this and I feel there must be something 
> simple I am overlooking.  

Why are you discarding SQLite's builtin and tested mutexes and then
effectively reimplementing your own to get the same effect?

Or bigger picture question what is it you are trying to achieve in the first
place?

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3MPIkACgkQmOOfHg372QQzjgCg3106pWiiUMuOQay+2ONv3G0c
ZvQAnAvBFXI+A8ae8tV9yXRmz7IZgid6
=jehy
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Visual Studio EE 2010

[Don Ireland]

For those that don't know:

VSEE2010 = Visual Studio Express Edition 2010

Don Ireland

-Original Message-
From: Don Ireland 
To: General Discussion of SQLite Database 
Sent: Thu, 12 May 2011 12:17 PM
Subject: Re: [sqlite] Visual Studio EE 2010

I'm using C++/CLI.

Thanks.

Don Ireland

-Original Message-
From: "Afriza N. Arief" 
To: General Discussion of SQLite Database 
Sent: Thu, 12 May 2011 11:23 AM
Subject: Re: [sqlite] Visual Studio EE 2010

On Thu, May 12, 2011 at 11:18 PM, Don Ireland  wrote:

> I downloaded and installed sqlite-dotnet-x86-3070600.zip.
>
> But when I attempt to add it as preference in VSEE2010, I find several dll
> files.  But none of them results in me being able to include a SQLite.h
> file.
>
>
What kind of environment you are developing for? Are you doing .NET
development (as in C#, C++/CLI, etc) or native development in C/C++ ?

For C/C++, get the downloads from http://sqlite.org/download.html and for
.NET, get the downloads from
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki

It might be easier for .NET development to use the pre-compiled binaries.

Regards,

Afriza N. Arief
___
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
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Can't send messages to list from pc?

[Don Ireland]

I use Thunderbird on my laptop and also have an Imap client on my Android.

I signed up for this list by sending a msg from Android.  Both email clients 
send from the same address.  
But when I send a message from my pc, it seems to end up in a vacuum because it 
never appears on the list.

Any ideas?

TIA!

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

Re: [sqlite] Visual Studio EE 2010

[Don Ireland]

I'm using C++/CLI.

Thanks.

Don Ireland

-Original Message-
From: "Afriza N. Arief" 
To: General Discussion of SQLite Database 
Sent: Thu, 12 May 2011 11:23 AM
Subject: Re: [sqlite] Visual Studio EE 2010

On Thu, May 12, 2011 at 11:18 PM, Don Ireland  wrote:

> I downloaded and installed sqlite-dotnet-x86-3070600.zip.
>
> But when I attempt to add it as preference in VSEE2010, I find several dll
> files.  But none of them results in me being able to include a SQLite.h
> file.
>
>
What kind of environment you are developing for? Are you doing .NET
development (as in C#, C++/CLI, etc) or native development in C/C++ ?

For C/C++, get the downloads from http://sqlite.org/download.html and for
.NET, get the downloads from
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki

It might be easier for .NET development to use the pre-compiled binaries.

Regards,

Afriza N. Arief
___
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] Transaction triggers?

[Nico Williams]

I believe I've got solutions to the various little problems I've run
into.  My experiments have helped me shed some light on what the
semantics of DB triggers should be, to the point where I think I've
reached stable conclusions about those semantics.  I'm also ready to
characterize performance and memory footprint impacts, and to describe
how DB triggers will work.  And I'm ready to solicit opinions and
advice regarding design and implementation as I want to contribute
this code to SQLite3, and I want to make sure to have code that is as
clean as possible -- any feedback will be greatly appreciated.

(Incidentally, I'm doing this work to enable other work in an existing
open source project.)

DB trigger semantics:

 - BEGIN triggers are AFTER BEGIN triggers, and they fire upon (and
before) the first INSERT/UPDATE/DELETE statement in a transaction, on
every INSERT/UPDATE/DELETE executed in auto-commit mode, or a BEGIN
IMMEDIATE, but they fire once and only once per-transaction.  BEGIN
triggers may throw errors, in which case the triggering statement will
fail with no way to override this (i.e. a triggering INSERT OR IGNORE
will not cause a BEGIN trigger exception to be ignored).

 - COMMIT triggers should (and if I can help it, will) come in two
varieties: BEFORE COMMIT and AFTER COMMIT.

   BEFORE COMMIT triggers can cause a commit to fail by RAISE()ing
exceptions, and therefore can run many times, but only once
per-commit, except that in auto-commit mode the triggering statement's
changes will be rolled back.

   AFTER COMMIT triggers cannot cause a commit to fail, and they
execute in their own transaction.  I will only code these if I can
easily make it so that the commit does its work without dropping the
lock so that the AFTER COMMIT trigger can run immediately.  Exceptions
thrown by AFTER COMMIT triggers will only result in their transaction
being rolled back with no effect on the prior transaction, and the
COMMIT statement will not return and error in such cases.

 - ROLLBACK triggers will only come in AFTER ROLLBACK flavor, and will
be very similar to AFTER COMMIT triggers, running after the triggering
event completes, and not being allowed to return errors.

No change to the CONNECT and DISCONNECT trigger semantics I described
earlier, except that I now know how to ensure that DISCONNECT triggers
fire no more than once per-connection.

I believe the above semantics are retrospectively obvious and
reliable, whereas my earlier proposed semantics were unclear and
clearly not finished.

How to use DB triggers:

 - CONNECT triggers are useful for: auditing purposes (of limited
value, of course, since there's no guarantee that a client will run
these triggers), and setup (e.g., load_extension()).  (A SQL function
roughly corresponding to the internal execExecSQL() function might be
useful for automatically setting up TEMP schema.)

 - AFTER BEGIN triggers could be useful for: logging, auditing, and
for demarcating the start of a write transaction.  For example, one
might ensure that there's a single row in a table named "TX", with a
unique (autoincremented) transaction ID to brand all rows of other
tables with, then one might use this to implement DB
synchronization/replication.

 - BEFORE COMMIT triggers should be used primarily for deferred
constraint checking, particularly of constraints that cannot easily be
expressed with existing, natively supported constraints.  If anyone is
interested I can give some elaborate examples of such constraints
based on extensive personal experience with an object-oriented DB back
in the late 90s (that DB is now open source too).

 - AFTER COMMIT triggers could be used for logging, auditing, and to
clean up after AFTER BEGIN triggers (though AFTER BEGIN triggers can
always clean up after the preceding AFTER BEGIN trigger firings, which
makes me think that AFTER COMMIT triggers add little value).

 - AFTER ROLLBACK triggers have very little utility in my view, mostly logging.

 - DISCONNECT triggers also have very little utility IMO, mostly
logging and auditing.

To make this all feasible I'm having to add a few opcodes: to check
whether a begin (or connect) trigger has run for the current
transaction, to mark the begin trigger as having run, an opcode to set
an address to jump to when a rollback exception is thrown and the
rollback completed, an opcode to mark the end of a DB trigger firing
(for housekeeping, otherwise COMMIT triggers cause the commit to fail
due to the OP_AutoCommit instruction thinking there are still active
statements writing in the same transaction), and maybe a couple of
others.

All DB trigger firings, excepting DISCONNECT, will be coded into
compiled statements other than SELECT.  The reason is that any one
prepared statement could be the one to trigger any CONNECT, BEGIN,
COMMIT (think auto-commit mode) and/or ROLLBACK triggers -- it all
depends on the context in which the statement in question is stepped.

PRAGMA statements may get CONNECT tr

[sqlite] Multi-threading Common Problem

[John Deal]

Hello All,

I have been using SQLite for a couple of years but have never posted to this 
list before.  I am sure my problem is common and am looking for ideas to solve 
it.

I have used SQLite extensively single-threaded with no problems (other than my 
own!).  I am currently working on another project adding SQLite functionality 
to a multi-threaded environment.  Here is my situation.

Ubuntu 10.04 64-bit.

Have used the SQLite3 library and compiled from source directly into the 
application.  Same results.

Multi-threaded compile flag configuration kept as the default and forced with 
sqlite3_config() to SQLITE_CONFIG_MULTITHREAD with no error reported.  Open is 
via SQLITE_OPEN_READWRITE | SQLITE_OPEN_NOMUTEX | SQLITE_OPEN_SHAREDCACHE 
flags.  I have tried this with and without shared cache.

When I use the above configuration multi-threaded but using only one DB 
connection in which only one thread is accessing the DB at a time, it works 
fine for both read and write.  I use OS read/write mutex in which all threads 
must obtain a write lock to get at the DB effectively forcing only one thread 
accessing the DB at one time.

When I allow multiple readers with each thread using a different DB connection 
(open with the same flags) and each thread having exclusive use of its DB 
connection (no sharing of connections) and if more than one thread is reading 
the DB at the same time, the DB becomes locked for writing even when all the 
reads are finished.  The DB is locked, not the OS mutex.  There are no DB 
writes.  How can the DB be locked for writes in this situation?  I test this 
with the sqlite3 program and opening the database while the application is 
running and try to do an insert.

I have been working for weeks on this and I feel there must be something simple 
I am overlooking.  Thanks for any help.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Common Multi-treaded Problem

[Igor Tandetnik]

On 5/12/2011 12:31 PM, John Deal wrote:
> When I allow multiple readers with each thread using a different DB
> connection (open with the same flags) and each thread having
> exclusive use of its DB connection (no sharing of connections) and if
> more than one thread is reading the DB at the same time, the DB
> becomes locked for writing even when all the reads are finished.

My first inclination would be to look for places where you leak active 
statement handles, by failing to reset or finalize statements. The read 
operation is not really finished until the statement is reset/finalized.
-- 
Igor Tandetnik

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

[sqlite] (no subject)

[John Deal]

Hello All,

I have been using SQLite for a couple of years but have never posted to this 
list before.  I am sure my problem is common and am looking for ideas to solve 
it.

I have used SQLite extensively single-threaded with no problems (other than my 
own!).  I am currently working on another project adding SQLite functionality 
to a multi-threaded environment.  Here is my situation.

Ubuntu 10.04 64-bit.

Have used the SQLite3 library and compiled from source directly into the 
application.  Same results.

Multi-threaded compile flag configuration kept as the default and forced with 
sqlite3_config() to SQLITE_CONFIG_MULTITHREAD with no error reported.  Open is 
via SQLITE_OPEN_READWRITE | SQLITE_OPEN_NOMUTEX | SQLITE_OPEN_SHAREDCACHE 
flags.  I have tried this with and without shared cache.

When I use the above configuration multi-threaded but using only one DB 
connection in which only one thread is accessing the DB at a time, it works 
fine for both read and write.  I use OS read/write mutex in which all threads 
must obtain a write lock to get at the DB effectively forcing only one thread 
accessing the DB at one time.

When I allow multiple readers with each thread using a different DB connection 
(open with the same flags) and each thread having exclusive use of its DB 
connection (no sharing of connections) and if more than one thread is reading 
the DB at the same time, the DB becomes locked for writing even when all the 
reads are finished.  The DB is locked, not the OS mutex.  There are no DB 
writes.  How can the DB be locked for writes in this situation?  I test this 
with the sqlite3 program and opening the database while the application is 
running and try to do an insert.

I have been working for weeks on this and I feel there must be something simple 
I am overlooking.  Thanks for any help.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Common Multi-treaded Problem

[John Deal]

Hello All,

I have been using SQLite for a couple of years but have never posted to this 
list before.  I am sure my problem is common and am looking for ideas to solve 
it.

I have basically the same situation as this thread:

---
On Wed, Jan 26, 2011 at 10:56 AM, Ian Hardingham  wrote:

> Hey guys.
>
> I am under the impression that there is no concurrent access to a single
> SQLite DB.  Ie if thread A is performing a query, and thread B trys to
> query, it will block until thread A is finished, no matter the query.
>
> 1.  Is this correct?
>

It is true if A and B are attempting to share the same database connection.
 Access to the database connection is protected by a mutex.


>
> 2.  Are there any fairly general workarounds of any kind?
>

Use a separate database connection for each thread.  Or better:  Use
processes instead of threads, as threads are evil.


>
> Thanks,
> Ian


I have used SQLite extensively single-threaded with no problems (other than my 
own!).  I am currently working on another project adding SQLite functionality 
to a multi-threaded environment.  Here is my situation.

Ubuntu 10.04 64-bit.

Have used the SQLite3 library and compiled from source directly into the 
applicaition.  Same results.

Multi-threaded compile flag configuration kept as the default and forced with 
sqlite3_config() to SQLITE_CONFIG_MULTITHREAD with no error reported.  Open is 
via SQLITE_OPEN_READWRITE | SQLITE_OPEN_NOMUTEX | SQLITE_OPEN_SHAREDCACHE 
flags.  I have tried this with and without shared cache.

When I use the above configuration multi-threaded but using only one DB 
connection in which only one thread is accessing the DB at a time, it works 
fine for both read and write.  I use OS read/write mutex in which all threads 
must obtain a write lock to get at the DB effectively forcing only one thread 
accessing the DB at one time.

When I allow multiple readers with each thread using a different DB connection 
(open with the same flags) and each thread having exclusive use of its DB 
connection (no sharing of connections) and if more than one thread is reading 
the DB at the same time, the DB becomes locked for writing even when all the 
reads are finished.  The DB is locked, not the OS mutex.  There are no DB 
writes.  How can the DB be locked for writes in this situation?  I test this 
with the sqlite3 program and opening the database while the application is 
running and try to do an insert.

I have been working for weeks on this and I feel there must be something simple 
I am overlooking.  Thanks for any help.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Visual Studio EE 2010

[Afriza N. Arief]

On Thu, May 12, 2011 at 11:18 PM, Don Ireland  wrote:

> I downloaded and installed sqlite-dotnet-x86-3070600.zip.
>
> But when I attempt to add it as preference in VSEE2010, I find several dll
> files.  But none of them results in me being able to include a SQLite.h
> file.
>
>
What kind of environment you are developing for? Are you doing .NET
development (as in C#, C++/CLI, etc) or native development in C/C++ ?

For C/C++, get the downloads from http://sqlite.org/download.html and for
.NET, get the downloads from
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki

It might be easier for .NET development to use the pre-compiled binaries.

Regards,

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

Re: [sqlite] Example/Tutorial for "extension_functions.c" in C/C++ Prog With "sqlite3.c"

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/10/2011 01:24 PM, Mays, Steve wrote:
> Question 1.)  Can "exentension_functions.c" be compiled along with
> "sqlite3.c" into one executable?
> 
> Question 2.)  If so, how?
> 
> Question 3.)  If "exentension_functions.c" be compiled into one
> executable along with "sqlite3.c", do I need to do anything special or
> will sqlite3_exec() know what to do with queries like:

You can compile together into one binary but the SQLite main code won't know
that your code co-exists.  There are two options available to you:

1 - [Not recommended] Patch the internal openDatabase method to call your
init method (this is how the extensions distributed with SQLite are added).

2 - Call sqlite3_auto_extension from your code that does SQLite initialization.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3MAB8ACgkQmOOfHg372QT+mQCfXNxVKe+mmV20tnjR/+2YAx6e
9H0AnRlbEvc+1OpMr2l6zlECqZOO0oWE
=V9CH
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Visual Studio EE 2010

[Don Ireland]

I downloaded and installed sqlite-dotnet-x86-3070600.zip.

But when I attempt to add it as preference in VSEE2010, I find several dll 
files.  But none of them results in me being able to include a SQLite.h file.

What am I doing wrong?

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

Re: [sqlite] Blob newbie problem

[StyveA]

Black, Michael (IS) wrote:
> 
> Do I understand you're still seeing a segfault?  I assume you're not
> seeing your "Year retrieved..." statement?
> 
> You haven't showed us your table definition.
> 
> Change your strcmp to strcasecmp and see if that fixes it for you.
> 
> Michael D. Black
> 
> Senior Scientist
> 
> NG Information Systems
> 
> Advanced Analytics Directorate
> 
> 

Yes I was still seeing a segfault but that's ok, I don't know exactly what
was the error 'case I've just added "int data" and replaced :
memcpy(&blob, argv[i], sizeof(blob)); 

by

memcpy(&data, argv[i], sizeof(blob)); (as well for the printf)

and it works fine.. strange.. maybe I need to make an
sqlite3_exec(RESET,...) ?
recompiled the code and it works well now..

but thanks a lot :)

Best regards,

--
Styve


-- 
View this message in context: 
http://old.nabble.com/Blob-newbie-problem-tp31602374p31602911.html
Sent from the SQLite mailing list archive at Nabble.com.

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

Re: [sqlite] Blob newbie problem

[Igor Tandetnik]

StyveA  wrote:
> I tried with your tips, and I've seen that I was missing the call of my
> callback function, and now the segfault is in it..

Personally, I vastly prefer sqlite3_step / sqlite3_column* interface to 
sqlite3_exec. I never use the latter except for one-liner statements like BEGIN 
or COMMIT - certainly not for SELECT statements. I strongly suggest you try it 
this way.

Is it possible that some NULL values ended up in the database during your prior 
unsuccessful attempts? In this case, argv[i] would be NULL, and then memcpy 
would crash. Delete the database file, start from scratch.
-- 
Igor Tandetnik

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

Re: [sqlite] Blob newbie problem

[Black, Michael (IS)]

Do I understand you're still seeing a segfault?  I assume you're not seeing 
your "Year retrieved..." statement?



You haven't showed us your table definition.



Change your strcmp to strcasecmp and see if that fixes it for you.





Michael D. Black

Senior Scientist

NG Information Systems

Advanced Analytics Directorate




From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of StyveA [styve.at...@technicolor.com]
Sent: Thursday, May 12, 2011 7:39 AM
To: sqlite-users@sqlite.org
Subject: EXT :Re: [sqlite] Blob newbie problem




Igor Tandetnik wrote:
>
> Prepare doesn't touch the database in any way. It just parses the text of
> the statement, and prepares execution plan. Step is where the real work is
> done.
>
> You need to issue BEGIN statement if you want to start an explicit
> transaction (and then COMMIT or END to commit it, or ROLLBACK to roll it
> back). If you don't, then each individual statement executes in its own
> implicit transaction, which automatically starts when you first call
> sqlite3_step, and commits when you call sqlite3_reset or sqlite3_finalize
> (or rolls back if the statement fails).
> --
> Igor Tandetnik
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>

Well thanks for this informations, that's better in my mind !

I tried with your tips, and I've seen that I was missing the call of my
callback function, and now the segfault is in it..

after that it should be ok I suppose..

Here are the changes :

http://old.nabble.com/file/p31602596/example.c example.c

I've removed the END line, and added the BEGIN.
I've changed my mistake about "int blob".

--
styve
--
View this message in context: 
http://old.nabble.com/Blob-newbie-problem-tp31602374p31602596.html
Sent from the SQLite mailing list archive at Nabble.com.

___
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] Blob newbie problem

[StyveA]

Igor Tandetnik wrote:
> 
> Prepare doesn't touch the database in any way. It just parses the text of
> the statement, and prepares execution plan. Step is where the real work is
> done.
> 
> You need to issue BEGIN statement if you want to start an explicit
> transaction (and then COMMIT or END to commit it, or ROLLBACK to roll it
> back). If you don't, then each individual statement executes in its own
> implicit transaction, which automatically starts when you first call
> sqlite3_step, and commits when you call sqlite3_reset or sqlite3_finalize
> (or rolls back if the statement fails).
> -- 
> Igor Tandetnik
> 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> 

Well thanks for this informations, that's better in my mind !

I tried with your tips, and I've seen that I was missing the call of my
callback function, and now the segfault is in it..

after that it should be ok I suppose..

Here are the changes :

http://old.nabble.com/file/p31602596/example.c example.c 

I've removed the END line, and added the BEGIN.
I've changed my mistake about "int blob".

--
styve
-- 
View this message in context: 
http://old.nabble.com/Blob-newbie-problem-tp31602374p31602596.html
Sent from the SQLite mailing list archive at Nabble.com.

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

Re: [sqlite] Blob newbie problem

[Igor Tandetnik]

StyveA  wrote:
> For the COMMIT/END point,  I though that sqlite_prepare(..) was sufficient
> to do it, so Begin is mandatory?

Prepare doesn't touch the database in any way. It just parses the text of the 
statement, and prepares execution plan. Step is where the real work is done.

You need to issue BEGIN statement if you want to start an explicit transaction 
(and then COMMIT or END to commit it, or ROLLBACK to roll it back). If you 
don't, then each individual statement executes in its own implicit transaction, 
which automatically starts when you first call sqlite3_step, and commits when 
you call sqlite3_reset or sqlite3_finalize (or rolls back if the statement 
fails).
-- 
Igor Tandetnik

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

Re: [sqlite] Blob newbie problem

[StyveA]

Igor Tandetnik wrote:
> 
> StyveA  wrote:
>> I'm a newbie using sqlite3, and i'm trying to save in a database some
>> blob
>> datas (just string and integer),
>> but I can't get my data back.. I just obtain a segfault..
>> I have searched in forums, but did'nt find anything that could help me..
>>
>> int *blob;
>> blob = 1990;
>> sqlite3_bind_blob(ppStmt, 1, blob, sizeof(blob), SQLITE_TRANSIENT);
> 
> You are aksing SQLite to read some bytes from address 1990. This address
> is likely invalid, hence the segfault. I suspect you meant
> 
> int blob;
> blob = 1990;
> sqlite3_bind_blob(ppStmt, 1, &blob, sizeof(blob), SQLITE_TRANSIENT);
> 
> Though it's not clear why you want to store a simple integer as a blob,
> and not as an integer. I assume it's just a toy example.
> 
> 
>> sqlite3_exec(db, "COMMIT", NULL, NULL, NULL);
>> sqlite3_exec(db, "END", NULL, NULL, NULL);
> 
> First, COMMIT and END are synonyms, they do the same thing. Second, you've
> never executed BEGIN, so you shouldn't run COMMIT (or END) either. If you
> check the return code of these sqlite3_exec calls, you'll see they have in
> fact failed.
> -- 
> Igor Tandetnik
> 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> 

Thanks for answer and the advises,

In fact, I'm storing an integer just 'cause my goal is to store data without
knowing their type, it can be integer or text..
So here I'm just trying with integer as a starting point.

For the COMMIT/END point,  I though that sqlite_prepare(..) was sufficient
to do it, so Begin is mandatory?

Regards,

Styve
-- 
View this message in context: 
http://old.nabble.com/Blob-newbie-problem-tp31602374p31602513.html
Sent from the SQLite mailing list archive at Nabble.com.

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

Re: [sqlite] Blob newbie problem

[Igor Tandetnik]

StyveA  wrote:
> I'm a newbie using sqlite3, and i'm trying to save in a database some blob
> datas (just string and integer),
> but I can't get my data back.. I just obtain a segfault..
> I have searched in forums, but did'nt find anything that could help me..
>
> int *blob;
> blob = 1990;
> sqlite3_bind_blob(ppStmt, 1, blob, sizeof(blob), SQLITE_TRANSIENT);

You are aksing SQLite to read some bytes from address 1990. This address is 
likely invalid, hence the segfault. I suspect you meant

int blob;
blob = 1990;
sqlite3_bind_blob(ppStmt, 1, &blob, sizeof(blob), SQLITE_TRANSIENT);

Though it's not clear why you want to store a simple integer as a blob, and not 
as an integer. I assume it's just a toy example.


> sqlite3_exec(db, "COMMIT", NULL, NULL, NULL);
> sqlite3_exec(db, "END", NULL, NULL, NULL);

First, COMMIT and END are synonyms, they do the same thing. Second, you've 
never executed BEGIN, so you shouldn't run COMMIT (or END) either. If you check 
the return code of these sqlite3_exec calls, you'll see they have in fact 
failed.
-- 
Igor Tandetnik

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

[sqlite] Blob newbie problem

[StyveA]

Hello,
I'm a newbie using sqlite3, and i'm trying to save in a database some blob
datas (just string and integer),
but I can't get my data back.. I just obtain a segfault..
I have searched in forums, but did'nt find anything that could help me..

Here is my code :
http://old.nabble.com/file/p31602374/example.c example.c 

Regards,

Styve
-- 
View this message in context: 
http://old.nabble.com/Blob-newbie-problem-tp31602374p31602374.html
Sent from the SQLite mailing list archive at Nabble.com.

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

Re: [sqlite] Can I dynamically select a table?

[Igor Tandetnik]

John  wrote:
> I don't see how that helps. Let's say I have table with rules which
> determine from which view to select:
> 
> create rules_table
> (condition integer, myview integer);
> 
> insert into rules_table values (1,10);
> insert into rules_table values (2,20);
> insert into rules_table values (3,30);
> insert into rules_table values (4,40);
> 
> I would use this query to determine which view to use:
> 
> select myview
> from rules_table
> where condition = :condition_in;

I'm not sure I understand. What other tables do you have? How does an integer 
10 (or 20, or 30, or 40) tell you which of these tables to use?
-- 
Igor Tandetnik

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

Re: [sqlite] SQLITE return codes for insert/delete/update/select

[George Brink]

On 5/11/2011 3:52 PM, cricketfan wrote:
>
> I dont know if it is just me but I find the return codes for SQL operation
> quite confusing. I am new to SQLITE, have learnt a few things and wanted to
> know if going in the correct direction,
You are thinking in the wrong direction.
SQLITE_DONE means that some command was send to database engine and 
database engine processed it correctly. Nothing more.
It is a common behavior FOR ALL client-server architecture. Client sends 
a command to the server, server replays "can do" or "cannot do, because".

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