On 2 Jul 2014, at 1:00pm, Grzegorz Sikorski <g.sikor...@kelvatek.com> wrote:
> On 02/07/14 12:20, Simon Slavin wrote: >> On 2 Jul 2014, at 12:02pm, Grzegorz Sikorski <g.sikor...@kelvatek.com> wrote: >> >>> My code works fine up to about 1020 connections to the database. After >>> around this number, I get an error "unable to open database file". [snip] >> This should not happen. But I don't know why it would happen. I have seen >> individual apps make more than 5000 connections to SQLite databases (not >> concurrently, but closing one before opening another) without problems. >> Mind you, that was on a desktop computer, not under iOS. > My application has to deal with concurrent connections to different database > files and sometimes do ATTACH/DETACH to another file (due to sharding). It should be working. I can understand a problem with 1020 connections at the same time: you run out of file handles. And SQLite usually opens at least two files per connection: database file and journal file, so you have half the file handles you expect. But if you're correctly closing files and never have more than a few open at the same time this shouldn't be a problem. >> Please make sure you are checking the results returned by /all/ sqlite3_ >> calls, including _close(), and reporting all errors. Don't check just the >> results returned by operations which make changes to the database. But if >> everything returns SQLITE_OK then you shouldn't be having those problems. >> Please post more info, perhaps with the extended error code. > > I double checked, I always have SQLITE_OK from all calls up to one which > gives me this error (note it is not always sqlite_open_v2, sometimes it can > happen on step or close calls). Is there any simple way to get extended error > codes you mentioned form C/C++ level? I haven't seen any API (I use > sqlite3_errmsg, sqlite3_errstr and sqlite3_errcode). Sorry, I should have pointed at the pages: <https://sqlite.org/c3ref/extended_result_codes.html> <https://sqlite.org/c3ref/c_ioerr_access.html> <http://www.sqlite.org/c3ref/c_abort_rollback.html> >>> I am not sure if there is any reason why keeping opened connection in >>> whole application lifetime is really something I should do? I would prefer >>> to open database only when it is needed, to avoid risk of file corruption >>> on power loss. >> If your app uses one database during one 'run', and need frequent access to >> it, there is no need to keep closing and reopening your database. As long >> as you use transactions properly and do not disable proper journal handing, >> you will find that SQLite is rock solid and you do not need to keep closing >> a database to make sure it is updated. > This is probably true for SQLite3, however there is not many file systems > which guarantee the same level of confidence on power loss. We especially > observe frequent corruptions on most file systems (VFAT, EXT3, EXT4, UBIFS) > on FLASH type devices like microSD and raw NAND FLASH (even up to 30% cases). > EXT4 on microSD with the safest mounting options gives us best results > (corruption chance less that 10%, depending on SD card type). I would guess that your device drivers are not enforcing the order in which write commands are executed. Unfortunately this is basic to the ACID abilities of SQLite and lacking it means that even closing the database and reopening it again is not going to guarantee uncorrupted data. There is nothing you can do about this if you lack in-order execution. If your file system or device driver has an operation which enforces in-order execution, you should pick it. For hysterical reasons, this option or command is often called 'EIEIO'. As for the rest, I'm sorry I somehow decided you were using iOS. Sorry. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
