I don't know enough about Sqlite internals to understand how these two processes clash and why SYNCHRONOUS=OFF makes a difference but would say that logic indicates that it is the SVN which is behaving badly as it should be transparent to all applications, particularly ones like Sqlite which don't do anything out of the ordinary for file access.

If you continue to use the SVN software a work-around to try and bypass the race condition would be to retry the sqlite3_open after a short pause when you intercept a CANTOPEN status.
JS

Costas Stergiou wrote:
Hello John,
I think I managed to trace the error (with the hint of Richard).
It is related to the Tortoise SVN client that I have installed on my PC.
This software includes a low level driver that intercepts all file accesses
and creates overlay icons on the windows explorer to show the status (e.g.
commited, new, etc) of files in folders. There is a process that handles
this called TSVNCache.exe.

I managed to trace this using the FileMon util from sysinternals.com: when
the error occurred, the TSVNCache process was attempting to read the file
and obviously sqlite could not access it.
It is VERY interesting though to see the series of disk events that lead to
this problem. I attach the log file from filemon that shows the error: the
error occurs at line 826 (the file that fails to be opened is
testsqlite3_2.db3). Notice that at line 827 the TSVNCache.exe attempts to
open/query this file

Initially, I was informed of this problem from a user with an antivirus: it
seems that this is a more general issue that can happen when a user is
running any type of 'file activity capturing' program (like TortoiseSVN or a
antivirus app). Well, to be honest I don't know if this is a design flaw in
the Tortoise SVN client of the sqlite engine fails to check something before
accessing the file that should normally do.

I did check the following code in a Win98 machine and 2 Virtual PCs (WinXP
and Win98) and they gave no errors (of course, no antivirus or SVN was
active there).

It seems to me that in order to be sure that this error does not occur in a
user's PC, the only safe way is to set "PRAGMA synchronous=OFF" but this is
not a safe thing to do. What else would you propose? Do you believe that a
'fix' could be made for this (if we assume that this is indeed a flaw of
sqlite and not a flaw of a 3rd party app)?
Costas



-----Original Message-----
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Κυριακή, 4 Ιουνίου 2006 9:24 πμ
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Random error SQLITE_CANTOPEN on Windows XP SP2 with
sqlite3_exec

If your close is not returning an error then the finalize is OK.

Are you using a local or network drive?  Any other information about
your configuration?  Can you open the file which gave the CANTOPEN
message using some other program?

When you make SYNCHRONOUS=OFF you stop Sqlite from verifying that data
has been written to disk.  When you get this error does the journal file
 for that database still exist?


Costas Stergiou wrote:

Hello John,
Thank you for your answer but I suspect this is not the reason for the
following cases:
1. I modified the code to check for the sqlite3_close return value and

it

never fails; the error keeps happening though
2. If I remove completely the sqlite3_close statement, the error still
occurs
3. In my actual application, I don't open so many dbs: I open about 7

and I

do many transactions in each one (and do not close them until program

exit).

4. The problem is related to this post:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg15494.html My

case is

exactly the same (although I cannot step into the c code to see what is
happening).
5. Why does the error goes away when I set 'PRAGMA synchronous = off;'?

I am afraid it is somehow related with the file handling routines and

WinXP

but I don't have the slightest idea what to do: the problem is that this

is

a really serious issue and, if it is not my fault, a show-stopper for

winXP

usage of SQLITE3.

Costas




-----Original Message-----
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Κυριακή, 4 Ιουνίου 2006 4:05 πμ
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Random error SQLITE_CANTOPEN on Windows XP SP2

with

sqlite3_exec

You don't test for an error on your close statement.  I suspect that the
Sqlite databases are not being closed because activity is not finalized.
  Your error pops up when you have a very large number of databases

open.


JS

Costas Stergiou wrote:


Hello everyone,

I lately came upon a very strange error that occurs at random times. I
managed to trace down and produce a small piece of code to reproduce

it.

I am using Delphi and the sqlite3.dll (latest) but I am sure that this

error


is not related to something other than the engine. Here is a code that
produces this error (read almost like pseudo-code):



var

i, j: Integer;

s: String;

db: pointer;

MSG: pchar;

begin

for i:=1 to 30 do begin

  s := 'testsqlite3_' + inttostr(i) + '.db3';

  deletefile(s);

end;



for i:=1 to 30 do begin

  s := 'testsqlite3_' + inttostr(i) + '.db3';

  sqlite3_open(pchar(s), db);

  //sql_exec(db, 'PRAGMA synchronous = off;');

  Assert( sqlite3_exec(db, pchar('create table t1(i1 int, i2 int)'),

nil,


nil, msg) = SQLITE_OK );

  Assert( sqlite3_exec(db, pchar('create table t2(i1 int, i2 int)'),

nil,


nil, msg) = SQLITE_OK );

  sqlite3_close(db);

end;

end;



What I am doing here is just creating 20 test databases and creating 2
tables in each one of these. That's all.

To repeat this error, the code above may need to be repeated some times
(some time it gives the error, some other it doesn't). Between

invocations


of the code it would be good to wait 1 second (I put it on a form and
associate it with a button; then I press the button repeatedly until I

get


the error, usually in 2-3 clicks).



Now, if I uncomment the "PRAGMA synchronous=off" command, the error

goes

away!

Also, if I remove the second create table command, I have no problem

again


(the problem is not associated with the 'create table command'

actually).



Any help or insight on the above will be very valuable since I am

completely


stack with it.

Thanks,

Costas





Reply via email to