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
