On 7/8/2013 12:09 AM, James K. Lowden wrote:
On Thu, 04 Jul 2013 16:08:38 -0400
Igor Tandetnik <i...@tandetnik.org> wrote:
On 7/4/2013 3:15 PM, James K. Lowden wrote:
This weird case is one of (I would say) misusing the connection.
IMO SQLite should return an error if prepare is issued on a
connection for which a previous prepare was not finalized or
reset. That would forestall discussions like, this and prevent
confusion and error.
SQLite worked this way, years ago. At some point, the restriction was
removed by popular demand. It is hugely convenient to be able to
manipulate one table as you iterate over another.
Why not simply open a separate connection, and allow the library to do
its job?
The library would do its job by preventing the second connection from
writing to the database while the first connection reads from it. Which,
of course, would defeat the purpose of the exercise. You seem to assume
per-table locking; SQLite doesn't do that - a transaction locks the
whole database file.
No other DBMS I know of willingly
allows a single process to corrupt the results of a SELECT statement
by calling other functions.
How many other embedded DBMS have you worked with? Your indignation
would be perfectly reasonable when directed towards a traditional
client-server database - but not really an embedded one.
--
Igor Tandetnik
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
