Re: [sqlite] Multi-threading.

2005-07-29 Thread 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,

Re: [sqlite] Multi-threading.

2005-07-29 Thread 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 jav

RE: [sqlite] Multi-threading.

2005-07-29 Thread 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 tak

RE: [sqlite] Multi-threading.

2005-07-29 Thread Tim McDaniel
K. Haley wrote: > 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. Not to nitpick, but since everyone else is, Win32 absolu

Re: [sqlite] Multi-threading.

2005-07-29 Thread Puneet Kishor
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.

2005-07-29 Thread 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

Re: [sqlite] Multi-threading.

2005-07-29 Thread 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.

2005-07-29 Thread 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

RE: [sqlite] Multi-threading.

2005-07-29 Thread 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: s

Re: [sqlite] Multi-threading.

2005-07-29 Thread 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 win

Re: [sqlite] Multi-threading.

2005-07-29 Thread 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

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

2005-07-29 Thread 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. ..

Re: [sqlite] BLOB field returns as TEXT type

2005-07-29 Thread 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 PR

Re: [sqlite] BLOB field returns as TEXT type

2005-07-29 Thread 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 -

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

2005-07-29 Thread 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 ca

[sqlite] BLOB field returns as TEXT type

2005-07-29 Thread 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

RE: AW: [sqlite] VB6 question

2005-07-29 Thread 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 Borro

Re[2]: [sqlite] sqlite3_compile missing?

2005-07-29 Thread 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