sqlite cross-table update

sqlite still won't do cross-table updates (stuff like update b from table1 b join table2 a on....), but there is that lame replacement:

  update b set b.f1 = (select f2 from a where a.f3=b.f3)

which of course has the side-effect of setting b.f1 to null where there isn't a corresponding record in a.

However, despite the magic that controls which rows actually get updated, the (select ...) bit is still just an expression like in standard SQL. Which means it can be an argument to coalesce():

  update b set b.f1 = coalesce((select f2 from a where a.f3=b.f3), b.f1)

While this isn't ideal it does solve the null problem.

sqlite performance

Definitely do follow the advice on stackoverflow about wrapping batch queries (eg a single query with 1000 insert statements) in their own transaction with

begin transaction
..
end transaction

I got a 2-orders of magnitude speed increase just from trying that, it was the only optimisation I needed.

HTTP::Daemon

Firefox and Iron are more forgiving with undelimited responses from HTTP::Daemon than Opera or other http clients (eg curl, or Uniface's UHTTP component*).

I find that the latter need to have their responses terminated with force_last_request, or accompanied by a correct Content-Length header ('correct' appears to be length($whatever_message_string_you_sent) ).

*Don't use this, it leaks memory like a sieve, spawn curl instead. And consider not using Uniface either

gcc link option

Option order is significant with gcc - if you want to link, eg, to the psapi library, you must not only use -l psapi but it must come after your source code in the command line:

gcc f:\src\c\ex-proclist.c -l psapi

(I picked that up from stackoverflow but it wouldn't let me vote it up)

Perl shift

shift doesn't seem to have a list context -

%settings = shift();  # no

%settings = @_;       # yes