Dan Kennedy wrote: > Is there any way your tests could be deleting a database > file while there is still an open sqlite connection to it? > > With 3.7.0, if the underlying database file is unlinked > while you are connected to it, then you try to write to > the database, you get SQLITE_IOERR_FSTAT. Earlier versions > would continue writing without causing an error. > > You cannot delete a file while it is open on windows, so > this doesn't come up on win32. > > This happened with a couple of Tcl tests too.
Perhaps. I do know now that someone else with nearly the same platform as mine, Mac OS X, is having the same failures, and has narrowed it down to multi-process access to the same database. Or specifically, they said this: I don't have time to investigate right now, but both failing tests seem to be connected with concurrent access to a table by two forked processes (the test script forks a child, which does concurrent access). At least in the second case, the DROP TABLE and CREATE TABLE commands are issued by the main process (after the child has dropped table2) and are supposed to succeed, so I believe there's something else going on than changed error codes (unless they trigger a bug within SQLite itself). In any event, I have and continue to forward any helpful comments on the sqlite-users list to the dbd-sqlite (Perl binding) developers list, since many of them aren't here. I anticipate the solution may be to change how the DBD::SQLite tests work. I'll report here once something's worked out. -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users