I'm afraid this is by design of sqlite: Sqlite will lock
the database during a writing transaction, I think no matter
if you open a 2nd connection using the readonly flag.
the typical solutions are:
a) retry your read attempt after you receive a busy error code until
it proceeds.
b) consider shared cache mode and pragma read_uncommitted = True;
hope this helps
Marcus
Tino Lange wrote:
> Hi all,
>
> I have written a program that opens a SQLIte3 database and writes in it most
> of the time via replace/update.
>
> If I do select like (no writes, really only reads) statements from some
> other process that carefully opens the database with "sqlite3_open_v2(...,
> SQLITE_OPEN_READONLY, ...)" the main (writing) application might get
> errcode=5 ermmsg='database is locked' errors when it tries to write while
> the other application (only!) reads.
>
> How is that possible? How to prevent?
>
> I would expect that the reading application might (of course) sometimes get
> "database is locked" errors, but the writing application should never.
>
> [ I have also realized that the sqlite3 commandline tool uses sqlite_open()
> and always opens in read/write mode. That's why I wrote my own reading
> application using sqlite3_open_v2 ]
>
> Thanks
>
> Tino
>
> _______________________________________________
> 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
