> CREATE TEMP TRIGGER seems to be the culprit, though I can't be sure. It is way too early in your debugging process to be naming culprits. You not only cannot be sure -- such thinking is likely to distract or derail the debugging that needs to be done. What you have learned (apparently) is that the problem becomes manifest when (somehow) the CREATE TEMP TRIGGER statement is run or the trigger executes. (Which is it?) But when a problem becomes manifestly obvious and when things went wrong which ultimately lead to such manifestation are usually different times, and often much different in terms of intervening activity. Heap corruption and its ultimate effects provide a good example. (Is that happening?) Keith asked, "If you replace some_function() with a different function (example, datetime) do you get the same result?" Seeing no answer to that question, I think you clearly have not begun to to flush out the bugs in your own code. If you are using SQLite correctly, its behavior should be no different between a single-threaded environment and a multi-threaded one, except of course for the possibilities arising from DB operation ordering and interaction. I would consider such evidence as "It's fine single-threaded but fails multi-threaded." to be a potent clue, leading me to see if my home-spun write-access protection is working and to see if the same sequence of DB operations that occur in the failure scenario produce the same problem when they are forced to execute sequentially. As you surely know, multi-threaded applications provide a wondrous variety of ways to create bugs. You may be seeing nothing more than yet another proof of this.