On 7 Feb 2013, at 2:27pm, James Vanns <james.va...@framestore.com> wrote:
> Hi Simon. Yes, the connection is closed - the process that writes the DB file > isn't memory resident (meaning, it isn't a daemon). The connection is > implicitly closed (and transaction committed?) by the process terminating. Okay. I've previously seen a problem where file protections were made before the file was closed, and the closing process reset them. > The problem only arises when the file is hosted by an NFS server - locally, > we do not see the problem. I would be interested to know if handing a sequential file over the same NFS connection shows the same behaviour. This would use fread() which should trigger any caching that the operating system and file system implement for that type of connection. You could test this using a text editor and a very long text file. I haven't looked at the code for SQLite. As far as I know, even though you can tell SQLite that /you/ aren't going to make changes to the file, there's no way to tell it that nobody else is going to make changes between your SELECT commands. Consequently there's no way to force it to use the cache. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
