Thank you so much for all help. I really appreciate it. /"All the same, I'm guessing that http://www.sqlite.org/src/info/39f763bfc0will fix your problem."/
I gave this new src code from the src tree a shot, but I seem to be getting the same behavior. Interestingly though, I tried enforcing my own serialization of the execution of the insert operations being called from the different threads with a mutex such that the code that performs the inserts is called sequentially from each thread, and this seemed to fix things. I did not see any duplicate sql statements. (This is with the sqlite src provided in the link compiled with the --enable-threadsafe and --enable-cross-thread-connections which I assume sets the threading mode to serialized). This leads me to believe that it has to do with contention/blocking within sqlite as Simon explains: /"What I am guessing is happening is that sometimes sqlite3_trace() is called, but is eventually held up because of access contention, a situation where it can't go ahead because the database is locked. Eventually the database becomes free again and this thread can go ahead, at which point _trace() gets called again."/ I also tried using the sqlite_profile( ) function, but this seems to not keep the bound parameter values in the const char* sql statement text, and this also replicated statements (I could tell because an incorrect number of INSERTS were printed). I greatly appreciate any other thoughts on what my problem could be. -- View this message in context: http://sqlite.1065341.n5.nabble.com/sqlite3-trace-threadsafe-tp64004p64030.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users