On 5 Apr 2012, at 3:04pm, Andreas Wiencke <wien...@flyingdog.de> wrote:
> I have a question regarding the locking in Sqlite3: Does Sqlite3 lock the > entire database when there is a lock on only one table? Yes. In fact it locks the entire database when there's only reason to lock one row. Either nothing or everything is locked. > In my code I want to read from one table and write the results to another > table. But if I don't fetch all the results and close the reading > connection, I cannot write to another table in the same database. As a rule, even though SQLite allows you to do a SELECT in many steps bit by bit, you shouldn't mess with the contents of the database in the middle of a SELECT. I'm not saying that it will (always, sometimes) fail, merely that a SELECT should be considered atomic. > Is this the intended behavior? And how could I work around that? Various ways. You can buffer your writes until you've finished your reads, either by accumulating the values in an array or by making a really long string of INSERT commands. If you have an extremely long database you're searching then you can use a cursor technique to iterate through the database bit by bit, with each SELECT fetching just the next record until there are no more records. Much slower but it lets you get through multi-gigabyte databases without using lots of memory. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
