Re: [sqlite] What is the column value after ALTER TABLE ADD COLUMN?

2007-05-18 Thread Tomash Brechko
On Fri, May 18, 2007 at 14:00:21 -0500, Doug Nebeker wrote: > UPDATE xyz SET newcol=function(other_column) WHERE newcol=null; > > Both of the above fail. What is the value in newcol? The value is NULL, however you have to say "IS NULL": UPDATE xyz SET newcol=function(other_column) WHERE

[sqlite] Re: What is the column value after ALTER TABLE ADD COLUMN?

2007-05-18 Thread Igor Tandetnik
Doug Nebeker <[EMAIL PROTECTED]> wrote: UPDATE xyz SET newcol=function(other_column) WHERE newcol=null; NULL is never equal to anything, not even another NULL. Make it UPDATE xyz SET newcol=function(other_column) WHERE newcol is null; Igor Tandetnik

[sqlite] What is the column value after ALTER TABLE ADD COLUMN?

2007-05-18 Thread Doug Nebeker
I must be missing something obvious and I'm hoping someone can help me out. I have an existing table and add a new column: ALTER TABLE xyz ADD COLUMN newcol TEXT; Next I want to set some default values to the new column. Because this code could potentially get executed later, I'm trying to

RE: [sqlite] One more SQLite threading question

2007-05-18 Thread Ken
Dan, Can you explain to me how within the context of the test_server.c code that the sqlite3_enable_shared_Cache will improve concurrency, for a single DB file access? I just don't see where any concurrency is gained. Sure maybe some memory savings. But I must be brain dead, because I

RE: [sqlite] One more SQLite threading question

2007-05-18 Thread Ken
I would be interested in a version of SQLITE that handled threading in a much cleaner way. I have a need for a single process version that is threaded. But, where SQLITE locking is concerned each thread is really like a seperate Database connection. The locking occurs as a part of the Pager

RE: [sqlite] One more SQLite threading question

2007-05-18 Thread Doug Nebeker
> > Yes I did the same experiment with a lock that made thread A wait > > until B was finished. So actually only one thread can be active at the time. > > I don't see how the outcome of this experiment can be of any > > interest, as there is no time reduction any longer. But your guess is >

Re: [sqlite] One more SQLite threading question

2007-05-18 Thread Martin Gentry
Yeah, in the face of "mostly" I was guaranteed to assume it should still be avoided (I may need to not make many restrictions where its used). Thanks -Original Message- From: Dan Kennedy <[EMAIL PROTECTED]> Date: Fri, 18 May 2007 13:31:10 To:sqlite-users@sqlite.org Subject: Re:

Re: [sqlite] One more SQLite threading question

2007-05-18 Thread Dan Kennedy
On Thu, 2007-05-17 at 18:26 -0400, Martin Gentry wrote: > Can you be a bit more specific? :-) I ask because this is immediately > relevant to some code I'm writing today, and have been operating on the > understanding that I should honour the restriction. I'm fine with honouring > the