[EMAIL PROTECTED] wrote:
Dave Dyer <[EMAIL PROTECTED]> wrote:
The real problem is that sqlite assumes it "owns" the temporary
transaction file that it created, and can do anything it wants with it;
for example read, rename, or delete it.
I think this is a very reasonable assumption.
Any other process which
gets it's hooks into the file can obviously invalidate this assumption.
This is not at all obvious to someone who does not
user or program for windows.
The obvious quick fix is to retry these file operations that must
succeed,...
Can some windows programmers suggest patches to os_win.c to
implement this.
but the underlying problem is a fundamental one that deserves
to be addressed.
Yes, I agree. But microsoft is unlikely to address the
gross deficiencies in their filesystem. So I suppose it
will fall to me to find a work-around.
I'll look into the matter when I have a chance.
--
D. Richard Hipp <[EMAIL PROTECTED]>
The solution used by others (for example Firebird) is to create
exclusive lock on file (in case of Firebird it is database file) to
prevent this situation.However in case of sqlite.dll it not so obvious,
because there is no database engine working all the time.
Regards
Boguslaw Brandys
