Re: [sqlite] Multi-threading.

[Mrs. Brisby]

On Fri, 2005-07-29 at 14:29 -0700, Robert Simpson wrote:
> Threads are a tool ... sortof like a chainsaw.  Used properly, they can save 
> you time and accomplish your goal.  In the hands of an expert, you can even 
> make some impressive art.  Well, perhaps the latter only applies to 
> chainsaws, but you get the idea.  In the hands of the ignorant or 
> inexperienced, you can easily lop off an arm or a leg, or getting back to 
> threading, seriously undermine the integrity of your code.  Threading, like 
> chainsaws, can be dangerous if not used properly.

Agreed.


> > 20 years ago, people said the exact same thing about goto- the places
> > where it can help are in programs that don't often use them, but the
> > places where it DOESN'T HELP- and actually hurts, are the ones using
> > goto.
> 
> I used goto's back when I was programming on the Vic-20 and I only had 3k of 
> RAM to work with -- every byte was valuable back then.  I also couldn't 
> understand the various branches of my code a week later when I went to debug 
> it, so I had a love-hate relationship with gotos.

Like chainsaws, gotos aren't useful for every task.

> I don't use them primarily because they, like threads, are easily abused and 
> can potentially make your code extremely hard to follow.  Case in point, one 
> of the older programmers in my office uses goto's liberally (on one project 
> we discovered a 1:9 ratio of goto's in his code -- meaning 1 goto for every 
> 9 lines of code on average).  His code is unintelligible.  He has labels 
> inside his for() loops and goto's jumping in and out of them.  He's got code 
> leapfrogging all over creation, and its the sickest ugliest thing I've ever 
> witnessed.  Who in hell even knows if the stuff works -- its all but 
> impossible to understand without running it.

Agreed.

> > Now, if you're feeling like you're on a high horse, go ahead: point out
> > a single common platform where threads are the necessity.
> 
> That argument is silly.  There exist no *platforms* where multithreading is 
> a necessity.  The platform doesn't dictate whether threading is useful or 
> warranted for a given application.  The programmer decides that.

Hence the point. Look at the parent and grandparent. There are many
people posting on this thread that _believe_ that threads are a
necessity.

> The real problem many coders encounter when writing multithreaded 
> applications is that some of the underlying libraries they may be using may 
> include optimizations that make the library inherently unsafe in a 
> multithreaded environment.  For example, a library that uses a global 
> variable to store a handle to a database file, and all instances of the 
> object simply refer back to that global handle.  You could code all the 
> synchronization objects you like and make sure all the object instances 
> never cross a thread boundary, but in the end if the underlying library's 
> objects are all sharing a global variable unbenknownst to you, then your 
> code is still going to have a potentially lethal race condition.  I think 
> *this* is the major issue people are concerned about when they come to the 
> SQLite list asking if SQLite is threadsafe.

Right. But they don't ask that. They say "I found a bug in SQLite when
using threads".

Re: [sqlite] Multi-threading.

[Mrs. Brisby]

On Fri, 2005-07-29 at 16:22 -0600, K. Haley wrote:
> Mrs. Brisby wrote:
> 
> >Now, if you're feeling like you're on a high horse, go ahead: point out
> >a single common platform where threads are the necessity.
> >
> >Here's some hints:
> >
> >* it's not windows
> >* it's not unix
> >* it's not java (closures)
> >* it's not lisp (closures)
> >* it's not forth (coroutines)
> >* it's not macos (see unix)
> >* it's not gtk+ (closures/event pump)
> >
> Argh...  gtk+ uses threads on windows.  The g_io_channel async api is
> implemented this way.  This is done because windows has no async file io
> api.  There may be other places/platforms where glib/gtk+ uses threads.

Err, windows most certainly does have Async API.

RE: [sqlite] Multi-threading.

[Fred Williams]

Reminds me alt.C in the News Groups, arguing over curly bracket
placement :-(

-Original Message-
From: Puneet Kishor [mailto:[EMAIL PROTECTED]
Sent: Friday, July 29, 2005 5:23 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Multi-threading.


Fred Williams wrote:
> How 'bout Y'all take this off-line before I have to track you down and
> lay some Texas justice on both you...  Mentioning SQLite every few
> sentences does not mask this religious warfare.

this 'thread' is not going to die, no matter where you tell them to
'goto'

*cough*

...

Re: [sqlite] Multi-threading.

[K. Haley]

Mrs. Brisby wrote:


Now, if you're feeling like you're on a high horse, go ahead: point out
a single common platform where threads are the necessity.

Here's some hints:

* it's not windows
* it's not unix
* it's not java (closures)
* it's not lisp (closures)
* it's not forth (coroutines)
* it's not macos (see unix)
* it's not gtk+ (closures/event pump)




Argh...  gtk+ uses threads on windows.  The g_io_channel async api is
implemented this way.  This is done because windows has no async file io
api.  There may be other places/platforms where glib/gtk+ uses threads.



signature.asc
Description: OpenPGP digital signature

Re: [sqlite] Multi-threading.

[Bert Verhees]

Some class-libraries make multithreading programming really easy, piece 
of cake, even when there are points to synchronize again to a single 
thread (f.e. interface), it is easy. You do not need to be a genius to 
write multithreading/multithreaded code


kind regards
Bert Verhees

Re: [sqlite] Multi-threading.

[Robert Simpson]

Like it or not, you still don't have any idea what you are doing. They
[threads] are never the only solution, and they are rarely appropriate.

I'm certain I'm not being entirely clear on just how rare it is: Threads
so rarely help that the programs that they CAN help don't often use
them, and the programs that it DOESN'T HELP- nay actually hurts, are the
ones using threads.


I wouldn't generalize to *quite* this extreme, being as I have not written 
nor reviewed even a small fraction of a percent of the millions of programs 
written on various platforms.  However, I will say this:


Threads are a tool ... sortof like a chainsaw.  Used properly, they can save 
you time and accomplish your goal.  In the hands of an expert, you can even 
make some impressive art.  Well, perhaps the latter only applies to 
chainsaws, but you get the idea.  In the hands of the ignorant or 
inexperienced, you can easily lop off an arm or a leg, or getting back to 
threading, seriously undermine the integrity of your code.  Threading, like 
chainsaws, can be dangerous if not used properly.



20 years ago, people said the exact same thing about goto- the places
where it can help are in programs that don't often use them, but the
places where it DOESN'T HELP- and actually hurts, are the ones using
goto.


I used goto's back when I was programming on the Vic-20 and I only had 3k of 
RAM to work with -- every byte was valuable back then.  I also couldn't 
understand the various branches of my code a week later when I went to debug 
it, so I had a love-hate relationship with gotos.


I don't use them primarily because they, like threads, are easily abused and 
can potentially make your code extremely hard to follow.  Case in point, one 
of the older programmers in my office uses goto's liberally (on one project 
we discovered a 1:9 ratio of goto's in his code -- meaning 1 goto for every 
9 lines of code on average).  His code is unintelligible.  He has labels 
inside his for() loops and goto's jumping in and out of them.  He's got code 
leapfrogging all over creation, and its the sickest ugliest thing I've ever 
witnessed.  Who in hell even knows if the stuff works -- its all but 
impossible to understand without running it.



Now, if you're feeling like you're on a high horse, go ahead: point out
a single common platform where threads are the necessity.


That argument is silly.  There exist no *platforms* where multithreading is 
a necessity.  The platform doesn't dictate whether threading is useful or 
warranted for a given application.  The programmer decides that.


[snip]

No. In order to use threads with SQLite you need to know how to use
threads. In order to use threads with ImageMagick, you need to know how
to use threads. In order to use threads with PostgreSQL you need to know
how to use threads. In order to use threads with libmodplug you need to
know how to use threads.

Notice a common theme? All of these libraries require the user do their
own serialization, and yet people continue to ask "how do I make
OpenLDAP work with threads" when they really mean "how do I use
threads."


The real problem many coders encounter when writing multithreaded 
applications is that some of the underlying libraries they may be using may 
include optimizations that make the library inherently unsafe in a 
multithreaded environment.  For example, a library that uses a global 
variable to store a handle to a database file, and all instances of the 
object simply refer back to that global handle.  You could code all the 
synchronization objects you like and make sure all the object instances 
never cross a thread boundary, but in the end if the underlying library's 
objects are all sharing a global variable unbenknownst to you, then your 
code is still going to have a potentially lethal race condition.  I think 
*this* is the major issue people are concerned about when they come to the 
SQLite list asking if SQLite is threadsafe.



There isn't any grey area here. Threads are complicated- so complicated
that they screw up otherwise promising programmers into thinking that
they're necessary and/or easy, when they're clearly neither.


I absolutely 100% agree.  Threads are dangerous and their benefits should be 
weighed before applying them to your application(s).  Personally, I've 
written quite a few programs that have benefitted significantly from 
multithreading, most of them server-based.  Those particular apps would've 
crashed and burned horribly when placed under a heavy load without using 
threads, so one could argue that they were not only beneficial but necessary 
to their success.


Robert Simpson
Programmer at Large

RE: [sqlite] Multi-threading.

[Fred Williams]

How 'bout Y'all take this off-line before I have to track you down and
lay some Texas justice on both you...  Mentioning SQLite every few
sentences does not mask this religious warfare.

-Original Message-
From: Mrs. Brisby [mailto:[EMAIL PROTECTED]
Sent: Friday, July 29, 2005 3:15 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Multi-threading.


On Thu, 2005-07-28 at 07:42 -0500, Dennis Jenkins wrote:
> Mrs. Brisby wrote:
>
> >meanwhile, two threads attempting to multiplex access to a single
sqlite
> >handle are a) bound to be confused, and b) need those resource locks
> >anyway.
...

Re: [sqlite] Multi-threading.

[Mrs. Brisby]

On Thu, 2005-07-28 at 07:42 -0500, Dennis Jenkins wrote:
> Mrs. Brisby wrote:
> 
> >meanwhile, two threads attempting to multiplex access to a single sqlite
> >handle are a) bound to be confused, and b) need those resource locks
> >anyway.
> >
> >  
> >
> (background: I've been using threads on win32 since 1998.  Sometimes to 
> spread load across multiple CPUs, but usually just because I find it 
> simpler than state logic to do everything in one thread.  I'm not 
> entering into this debate on threads vs. non-threads.)

I find I use goto a lot. I find it's simpler than lots of if/break
scenarios.

I think you'd be surprised to find out that you might actually agree
with me :)


> I just want to know why anyone would code using multiple threads 
> accessing the same SQLITE connection object ( or handle or whatever you 
> want to call it).  I allocate a separate connection object for each 
> thread and have ZERO troubles with locking so long as I use transactions 
> properly.  Assuming a multi-threaded (with in the same process) 
> environment, what benefits are there to use a single (global?) SQLITE 
> object (protected by a mutex, semaphore, critical section, whatever)?  
> It seems so much more complicated and brittle.

The reason they would write their code this way is because they don't
know how to use threads. They think threads work differently than they
do.

And folks, this here is my whole point. Coming from the position of
someone who knows how to use threads: Why would anyone chose to use them
incorrectly. The only reasonable answer is that they simply don't know
how to use threads.

Threads complicate things. People think they "understand threads" long
before they actually do. Goto complicates things. People think they
"understand goto" long before they actually do.

They think they know the dangers of threads, and they think they know
the dangers of goto.

And yet, there are folks who vehemently avoid "goto" as if it were a
plague, that simply don't understand why people would just as
aggressively reject "threads".

Re: [sqlite] Multi-threading.

[Mrs. Brisby]

On Thu, 2005-07-28 at 08:44 -0400, Eli Burke wrote:
> Mrs. Brisby wrote:
> > My PII-350 easily handles 2 million local deliveries per hour, and it
> > fork()s for each one.
> > 
> > As has been mentioned: If you think threads are going to make your
> > program fast, you don't know what you're doing.
> 
> Like it or not, the world is bigger than just Unix. Some of us have to
> write code
> for other platforms, or even cross-platform. You can preach until you
> turn green
> about the dangers of threads in the hands of all the rest of us dumb
> idiots, but that
> doesn't change the fact that sometimes they are an appropriate (or the
> only) solution.

Like it or not, you still don't have any idea what you are doing. They
[threads] are never the only solution, and they are rarely appropriate.

I'm certain I'm not being entirely clear on just how rare it is: Threads
so rarely help that the programs that they CAN help don't often use
them, and the programs that it DOESN'T HELP- nay actually hurts, are the
ones using threads.

20 years ago, people said the exact same thing about goto- the places
where it can help are in programs that don't often use them, but the
places where it DOESN'T HELP- and actually hurts, are the ones using
goto.

Now, if you're feeling like you're on a high horse, go ahead: point out
a single common platform where threads are the necessity.

Here's some hints:

* it's not windows
* it's not unix
* it's not java (closures)
* it's not lisp (closures)
* it's not forth (coroutines)
* it's not macos (see unix)
* it's not gtk+ (closures/event pump)

That said: Writing kernel processes for the linux kernel requires a lot
of thread-think in that you have to keep all of your memory access
private. I generally suspect, however, that the people having problems
with threads _there_ aren't the same people who are having problems with
threads _here_.


> Mrs. Brisby wrote:
> > Maybe people think that SQLite should serialize its own internals. Maybe
> > that's why people keep saying this.
> [snip]
> > meanwhile, two threads attempting to multiplex access to a single sqlite
> > handle are a) bound to be confused, and b) need those resource locks anyway.
> 
> I don't think anyone is asking for SQLite to be serialized, or for it to
> work properly
> when a db handle is reused by multiple threads. Yes, there are a lot of
> questions about
> threads on the mailing list. Maybe it is because Kervin Pierre is
> right-- the documentation
> RE threads is poor.

SQLite doesn't have anything to do with threads. That's the problem.

What people miss is that they either think memory-chunk serialization is
automatic, or automatically provided by SQLite.

But SQLite isn't different from the majority of third-party libraries
out there, and if _THIS_ is what is tripping people up, then it should
be all the more evident that thread-think makes people dumb.

[[ personally: I don't think this is what's tripping people up. _I_
think that they really don't know how to use threads in the first
place. ]]


> It's no big secret that Dr. Hipp is in the "threads are bad" camp, and
> so getting helpful
> information means spending hours reading through old mailing list posts,
> sorting through the
> chaff, trying to figure out what behavior applies to the current
> software version. (a number
> of significant threading issues have been resolved since 3.0 was
> released). There is a short
> article in the wiki on threads, but you have to know to look for it.

No. In order to use threads with SQLite you need to know how to use
threads. In order to use threads with ImageMagick, you need to know how
to use threads. In order to use threads with PostgreSQL you need to know
how to use threads. In order to use threads with libmodplug you need to
know how to use threads.

Notice a common theme? All of these libraries require the user do their
own serialization, and yet people continue to ask "how do I make
OpenLDAP work with threads" when they really mean "how do I use
threads."

There isn't any grey area here. Threads are complicated- so complicated
that they screw up otherwise promising programmers into thinking that
they're necessary and/or easy, when they're clearly neither.


> Consider the lone FAQ entry on threading. It contains two helpful bits
> of advice. 1) Don't
> reuse db handles between threads. 2) Don't reuse db handles after
> fork(). Now imagine if
> that information was actually in a useful place, namely in the
> sqlite3_open API reference.
> Perhaps that would cut down on some new user confusion?

I doubt it. It's worth a shot though.

Re: [sqlite] [ANN] a full text search engine for sqlite3

[Puneet Kishor]

Pierre Aubert wrote:

Hello,
I wrote a small full text search engine for sqlite3. 


c'est très bon

I rolled my own using an inverted index, the /usr/share/dict that comes 
with the OS, and Perl. It works fine for my need, but having something 
like this written in C++ would be very fast.


..


Code is in C++ with some external dependancies 
(google sparsehash, libtextcat, and of course sqlite3.
It 
currently works under Linux 32bits and Cygwin, tested
with 
g++-3.4.4. Quality is Beta. Build/Install process
created 
yesterday this not well tested.


It is under a BSD license.

I wait for your feedback. In particular, any way to 
optimize performance at search time is of interest. 



I don't know any C++, so all I can do is watch the progress, but I will 
do so with great interest.

Re: [sqlite] BLOB field returns as TEXT type

[Edwin Knoppert]

Oops, forgot to use X before the storage (grrr!)

X'hexdata'

sqlite3_column_text returns a pointer to binary data wich i can copy by 
obtaining the columndata size.


BLOB type is now properly returned as well :)

Thanks anyway.





- Original Message - 
From: "Edwin Knoppert" <[EMAIL PROTECTED]>

To: 
Sent: Friday, July 29, 2005 4:21 PM
Subject: Re: [sqlite] BLOB field returns as TEXT type


Only the sqlite3_column_decltype() return "BLOB" but that might be any 
declared keyword.

Point is that the lib knows that it must return the data in hex notation.
I would like to know how i can determine this as well so i can convert the 
hex data back to normal.





- Original Message - 
From: "Edwin Knoppert" <[EMAIL PROTECTED]>

To: 
Sent: Friday, July 29, 2005 3:39 PM
Subject: [sqlite] BLOB field returns as TEXT type



I'm expecting SQLITE_BLOB when using sqlite3_column_type()
It keeps returning SQLITE_TEXT (3) while the field was created as BLOB.

The text returned from sqlite3_column_text() is in hex notation.
At this time i don't mind the wrong type nr as long i can distinguish the 
HEX blob data from ordinary fielddata (text e.o)
I have no problem with a conversion from hex to binary data, it's my wish 
to use a common function to return any fielddata requested as binary 
string data.

(And thus not knowing at forhand what datatype was stored)

How?

Re: [sqlite] BLOB field returns as TEXT type

[Edwin Knoppert]

Only the sqlite3_column_decltype() return "BLOB" but that might be any 
declared keyword.

Point is that the lib knows that it must return the data in hex notation.
I would like to know how i can determine this as well so i can convert the 
hex data back to normal.





- Original Message - 
From: "Edwin Knoppert" <[EMAIL PROTECTED]>

To: 
Sent: Friday, July 29, 2005 3:39 PM
Subject: [sqlite] BLOB field returns as TEXT type



I'm expecting SQLITE_BLOB when using sqlite3_column_type()
It keeps returning SQLITE_TEXT (3) while the field was created as BLOB.

The text returned from sqlite3_column_text() is in hex notation.
At this time i don't mind the wrong type nr as long i can distinguish the 
HEX blob data from ordinary fielddata (text e.o)
I have no problem with a conversion from hex to binary data, it's my wish 
to use a common function to return any fielddata requested as binary 
string data.

(And thus not knowing at forhand what datatype was stored)

How?

[sqlite] [ANN] a full text search engine for sqlite3

[Pierre Aubert]

Hello,
I wrote a small full text search engine for sqlite3. 

Basic ideas are as follow:
--
* use another sqlite3 file for storing full text index

  information
* store everything into sqlite3 (this is not the 
  fastest strategy in particular for inverted index)
* don't care too much about disk space constrains
  (ft3 use roughly 8x more space than initial datas)
* be resonnably efficient (index the 500k small 
  documents in the english part of dmoz.org in 2H on 
  my desktop PC, a search with frequent words take 
  around 3/5 seconds on 1 IDE disk whitout cache, and 
  less than 0,5 second if data in cache)

Support basic things:
-
* for words: stemming, metaphone, stopwords, 
  dictionnary, some statistics
* for scores: TFIDF, proximity
* special parsing for urls
* special parsing for topics (If you have some)
* web classical syntax for queries (support ±/""/:)
* make it easy to search from a php module
* configuration stored inside sqlite3
* language detection (currently unplugged)

Important Missing things:
-
* Trigger support (currently not an incremental 
  process, ft3_indexer reindex the full table)
* ICU integration
* language detection to be put in place and debug
* declare functions via sqlite3_func
* SQL for computing co-occurence table is slow/buggy
* It currently lacks a decent documentation which is 
  the next thing on my todo list.
* It is not integrated within sqlite3 but it may be in

  the future if I understand enough of sqlite3
internal. 

Example:

from dmoz.org rdf dump, 
extract every documents not under Top/World
dmozen.db3 =>  197MO 578k docs
dmozen.ft3 => 1704MO 646k words, 20,000k positions


I'm currently setting a project on sourceforge.net. 
You can temporary grab a source tarball here:

and static binaries for Linux here:


Code is in C++ with some external dependancies 
(google sparsehash, libtextcat, and of course sqlite3.
It 
currently works under Linux 32bits and Cygwin, tested
with 
g++-3.4.4. Quality is Beta. Build/Install process
created 
yesterday this not well tested.

It is under a BSD license.

I wait for your feedback. In particular, any way to 
optimize performance at search time is of interest. 

Pierre. 







___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

[sqlite] BLOB field returns as TEXT type

[Edwin Knoppert]

I'm expecting SQLITE_BLOB when using sqlite3_column_type()
It keeps returning SQLITE_TEXT (3) while the field was created as BLOB.

The text returned from sqlite3_column_text() is in hex notation.
At this time i don't mind the wrong type nr as long i can distinguish the HEX 
blob data from ordinary fielddata (text e.o)
I have no problem with a conversion from hex to binary data, it's my wish to 
use a common function to return any fielddata requested as binary string data.
(And thus not knowing at forhand what datatype was stored)

How?

RE: AW: [sqlite] VB6 question

[Steve O'Hara]

How does a C++ wrapper help someone using VB6?

Steve

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of RAY BORROR
Sent: 29 July 2005 05:22
To: sqlite-users@sqlite.org
Subject: Re: AW: [sqlite] VB6 question


I am using SQLite Plus sucessfully

Ray Borror

Gregory Letellier <[EMAIL PROTECTED]> wrote:
all the wrapper ar for 2.8 and i wan't use the 3.0
anyone known 3.0 wrapper ?

Steve O'Hara a écrit :

>Don't want to dampen your enthusiasm for this route but. why do you
>think there are so many VB wrappers for SQLite?
>
>It's because you can't use the SQLite DLL directly from VB - some functions
>will work but the essential ones won't. It's because the DLL returns things
>like pointers to arrays of pointers which is not very groovy in VB (in
fact,
>you would have to resort to some OS calls to unravel that).
>
>Use one of the wrappers.
>
>Steve
>
>
>
>
>
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]
>rg]On Behalf Of Gregory Letellier
>Sent: 27 July 2005 11:17
>To: sqlite-users@sqlite.org
>Subject: Re: AW: [sqlite] VB6 question
>
>
>Ok Thank's for your help i will trying this !!!
>
>[EMAIL PROTECTED] a écrit :
>
>
>
>>Hi,
>>
>>unfortunately this has to do with the C calling convention used by
>>
>>
>sqlite3.dll. By default DLLs compiled with C have the cdecl calling
>convention, but VB only supports the stdcall calling convention.
>
>
>>You must recompile sqlite using MS Visual C++ or other compiler and switch
>>
>>
>the default calling convention from cdecl to stdcall in the compiler/linker
>settings.
>
>
>>HTH
>>Michael
>>
>>
>>
>>
>>
>>>hello i'm trying to open a database with VB6 without wrapper
>>>
>>>i'm using sqlite3.dll
>>>
>>>and it's my code :
>>>
>>>Option Explicit
>>>Private Declare Function sqlite3_open Lib "sqlite3.dll" (ByVal filename
>>>As String, ByRef dbHandle As Long) As Long
>>>Private Declare Function sqlite3_open16 Lib "sqlite3.dll" (ByVal
>>>filename As String, ByRef dbHandle As Long) As Long
>>>Private Declare Sub sqlite3_close Lib "sqlite3.dll" (ByVal DB_Handle As
>>>Long)
>>>
>>>Private Sub Form_Load()
>>> Dim lRet As Long
>>> Dim lDbHandle As Long
>>> Dim sFilename As String
>>>
>>> sFilename = "c:\toto.db"
>>> sqlite3_open sFilename, lDbHandle
>>> MsgBox ("lRet=" & lRet)
>>> MsgBox ("ldbhandle=" & lDbHandle)
>>> sqlite3_close (lDbHandle)
>>>End Sub
>>>
>>>when i launch it, i've an error 49 : Bad DLL calling convention
>>>
>>>anyone can help me ? where is my fault ?
>>>
>>>thx
>>>Gregory Letellier
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>
>
>

Re[2]: [sqlite] sqlite3_compile missing?

[djm]

> I think you are looking at the sqlite2 documentation, not sqlite3!  

> sqlite_compile was changed to sqlite3_prepare in sqlite 3  (with very
> different schematics, so readily closely)

> sqlite3_step still exists, but it takes different arguments

Thanks. Have it now. I had downloaded the page for offline reading,
and therefore hadnt opened it via the link for the start page, which
was the only mention of version 2.

Re: [sqlite] How do I backup sqlite data file

[Cyril Scetbon]

sqliteX active.db .dump > backup.sql

Koji Namekata wrote:


Hi,

What is the most reasonable way to backup sqlite data file?

When applications using that db file are stopped, simple file copy `cp
active.db backup.db' works fine.  But with long running applications,
is it correct to assume asynchronous copy may result in inconsitent
state of the db file, and if so, how do I backup it?

Thanks in advance.

--
Namekata Koji