Please accept my apology for stating the obvious here (if it is obvious to you.) If we assume, (as I do), that the progress handler should have no side effects insofar as the SQLite library's operation is concerned, and takes negligible time compared to the work done by the library, then (it stands to reason that) we must focus on side-effects and execution time of your progress handler.<sup><b>1</b></sup> Hence, I would suggest an incremental approach to figuring out where your handler goes awry, starting with an empty, do-nothing-quickly version and progressing (so to speak) to your fully fledged version that *seems* to misbehave. I would expect, as your progress handler fledges, that it will suddenly exhibit the problematic behavior you report, and at that increment of fledging you will gain a pretty good idea as to why, or at least of what needs intensive study for side-effects or pokiness. Even if you dislike this trouble-shooting approach, something like it will be necessary to gain serious attention to your problem. As things stand now, your report can be paraphrased, "When I install my mystery progress callback, things go wrong such that my DB operation seems to never terminate." The natural question then is, "Well, what does that handler do?" > After about one hour, the callback function reported a call count of whooping 971,855,609,341 calls! So, this seemed to be the problem. I suggest a slight perspective shift: That (whopping count) seems to a manifestation of the problem. Excessive calls may be "the problem" as far as you care, but if your code is the cause of that, then treating it as mere library misbehavior is going to unduly compromise your debugging progress. ---- <b>1.</b> I read your post as saying that the library operations proceed as you expect and wish when no progress callback is in place.