Thank you for all your support. Thank you, Roger. You pointed out the most likely error: I didn't set the sqlite-task to exclusively use the connection when reading from the database, only when writing. I used a share lock when reading.
Thank you, Teg. You made me confident with having large databases. For a moment I believed that I couldn't have databases of some gigabyte. Patrik On 02/27/2012 12:14 AM, Patrik Nilsson wrote: > Thank you, Roger, for your piece of advice. I will consider it, but it > will be a great deal to rework. > > Patrik > > On 02/26/2012 11:41 PM, Roger Binns wrote: >> On 26/02/12 12:40, Patrik Nilsson wrote: >>> Yes. My program starts two thread, the main one and a worker. There >>> are mutexes so only one at a time can the sqlite interface. >> >> In previous postings to the mailing list when people do things like this, >> I believe that it turning out to be a threading bug in their program is >> 100%. The onus will be on you to prove that you do not have a threading bug. >> >> Some examples. Unless you call sqlite3_db_mutex you cannot safely get the >> error string. Unless you keep sqlite3_stmt per thread you can have memory >> changed underneath you. Unless you use SQLITE_TRANSIENT, the memory that >> gets used may not be what you intended (your symptoms correlate with this >> BTW). >> >> Even if you write perfect thread safe and correct code in 999 places in >> your code, getting the thousandth one slightly wrong is enough to cause >> problems. >> >> By far the safest thing to do is to either only do SQLite activity in one >> thread, or to give each thread its own sqlite3 connection. >> >> Roger >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
