On Mon, Jan 26, 2009 at 2:37 AM, John Machin <sjmac...@lexicon.net> wrote:
> On 26/01/2009 12:17 PM, Rickard Westerlund wrote:
>> On Sun, Jan 25, 2009 at 12:12 AM, John Machin <sjmac...@lexicon.net> wrote:
>>> So SELECT has the same problem as UPDATE. That would suggest to me that
>>> the next step would be to try the following:
>>>
>>> (1) SELECT *, (CASE .....END) FROM tags WHERE lft BETWEEN ? AND ?
>>> (2) SELECT * FROM tags WHERE lft BETWEEN ? AND ?
>>>
>>> and if (2) still finds no rows, we must be at the stage of asking you to
>>> show the whole of the minimal C program that demonstrates the problem.
>> At first I had the "*," part removed and forgot to mention that in my
>> haste, as well as testing with it. It apparently made a whole
>> difference, the SELECT statements work and give the desired results so
>> the previous suggestion was alright.
>
> That is mind-bogglingly confusing. Which previous suggestion? Care to
> itemise what appears to work and what appears not to work?
The one from an earlier reply, which I reported as not working.
> Could apparent lack of activity be due to the fact that "ret" is used
> but not initialised in the following function?
A mistake on my part, ret is used to look at the result of an SQL
statement which creates all the tables to use, but I forgot to remove
the error checking for the test case it seems.
On Mon, Jan 26, 2009 at 3:03 AM, John Machin <sjmac...@lexicon.net> wrote:
> (1) work out a case that causes the problem and hard-code the values
> into the demo program, or *PRINT* the six values that you are binding,
> so that we (that includes you!) can check that those values cause the
> conditions to be true
>
> (2) *CHECK* (and print!) the return value from each sqlite3_ function.
>
> /* Update the table. */
> for (i = 0; i < sizeof(updates)/sizeof(*updates); i++) {
> sqlite3_prepare_v2(db, updates[i], -1, &stmt, NULL);
> sqlite3_bind_int(stmt, 1, src_lft);
> sqlite3_bind_int(stmt, 2, src_rgt);
> sqlite3_bind_int(stmt, 3, move);
> sqlite3_bind_int(stmt, 4, displacement);
> sqlite3_bind_int(stmt, 5, affected_lft);
> sqlite3_bind_int(stmt, 6, affected_rgt);
> sqlite3_step(stmt);
> sqlite3_finalize(stmt);
> }
> Is that what your real code looks like? How do you know that that "for"
> statement is actually executed?
These things I have already tried (and printing the values to be
binded was necessary to construct that manual update statement), but I
usually clean up after myself whenever I litter my code with printf
statements. I suppose I should've had them included for the test case
though.
I think I have found the problem though, it seems it has to do with
locking. I have a function which find a tag by name, it can be used to
evaluate the existance of a label and get it's real name if it is an
alias (in the tag_aliases table). For this I leave the statement used
by it open, as I'm not sure what happens to the string retrieved from
it when it's finalized. But I'm thinking that because one SELECT
statement is still active, I cannot perform any updates. When this tag
finding function is commented out it work. Would I have to duplicate
the string and then finalize the statement?
I have updated the test case with the function that finds a tag if it
is of interest: http://www.acc.umu.se/~onionkgt/test.c
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
