> >If the previous process to access the database was in the middle of a write >but crashed before the write could complete, then your "read-only" process >will still need to write to the database in order to clean up the mess left >behind by the prior process before it can start its query. So perhaps your >"read-only" process is unable to open the rollback journal. > >Another possibility is that your SELECT needs to create some transient >intermediate tables to store intermediate results. Such tables are normally >created in /var/tmp (or wherever else it is appropriate to create temporary >files on your system) and then deleted at the end of the SELECT. If you >are out of space on /var/tmp or if you do not have write permission on >/var/tmp, you could get an SQLITE_CANTOPEN error.
Neither of these fits the scenario, which is multiple readers contending for access to a networked disk. The process receiving the SQLITE_CANTOPEN is only reading, and the error occurs randomly in one of many similar requests. There is no transaction. SQLITE_CANTOPEN appears to be recoverable only by retrying the query (or many by sqlite3_reset?). It seems out of spec that a simple query should fail randomly in the absence of a disk error. If this were an update query, the overall process ought to be prepared to do a retry, but a select query ought to just return SQLITE_BUSY until the data is available. Correct? It is likely that some low level and unexpected failure on a disk operation is occurring. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
