Tore, a couple of questions: A. How are your concurrent inserts implemented, in a multi threaded application or multi process? B. What type of error handling do you have in place for failures ? C. Do you use transactions? If so what how are they initiated? D. What do you mean by "high concurrency"?
In my view there is really no such thing as "high concurrency" just concurrency. You need to take care of the error codes from sqlite that indicate failure and 1. retry until success or you can just give up. Instead of just saying it don't work, could you provide an example? I have a concurrent applicaiton and It does work, Not once has sqlite dropped a record, it does return SQLITE_BUSY and in some cases SQLITE_LOCKED. Sqlite is not a concurrent write database. Meaning that you may not have two threads or even two processes concurrently writing to the database at the same time! Sqlite will return a sqlite_busy error. Check out the following: http://sqlite.org/lockingv3.html HTH, Ken Tore Austraatt <[EMAIL PROTECTED]> wrote: Thanks, but I'm afraid this don't add up. I have tested this in numerous examples. Concurrent INSERT's disappears into thin air, they leave no trace what so ever. It seems very strange if some of you haven't experienced simular problems...? John, PRAGMA sync = whatever does not remedy this either. Ken, locks are handled without any problem at all... Tore. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
