RE: [sqlite] journal - "Unable to open the database file"

[Allan, Mark]

Yes it would appear that the file is open read only. I cannot open the file in 
any other program to attempt to change the contents or truncate it.  It appears 
that the file is locked, but when using Unlocker to try to unlock it, it states 
that there is no locking handle on the file. Try to delete the file through 
unlocker, explorer or DOS and it will fail saying "It is being used by another 
process". I shutdown my pc and still get the same error. Spookily after a 
random amount of time the file will delete itself automatically. The only way 
to force its removal from the network is for me to ask a member of admin to do 
it for me.

I cannot be sure it is Windows Desktop Search that causes this. But it is the 
most likely candidate. The file is locked by one of two members of staff here, 
both of which run Windows Desktop Search. Noone else uses it and noone else has 
ever been found guilty of having the file open by admin. However I have tested 
this on a PC running Vista (with the db on a local file system however), Vista 
has file indexing built in as standard. The test program ran all weekend 
without exhibiting this same problem on Vista.


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2007 16:36
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] journal - "Unable to open the database file"
> 
> 
> "Allan, Mark" <[EMAIL PROTECTED]> wrote:
> > 3) Ask if anyone can offer any advise us as to what we can do 
> > to get around the problem of a journal file being locked and 
> > SQLite cannot delete it? Because at the moment if this situation 
> > occurs no one can write to that Db until the journal file has 
> > gone. Which is quite a severe problem...
> > 
> 
> While Windows Desktop Search has the journal file open, is the
> journal file read only?  Is it possible to change the content
> of the file or even truncate the file to zero length as long as
> the file is not deleted?
> 
> --
> D. Richard Hipp  <[EMAIL PROTECTED]>
> 
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 
> 
> 


DISCLAIMER:
This information and any attachments contained in this email message is 
intended only for the use of the individual or entity to which it is addressed 
and may contain information that is privileged, confidential, and exempt from 
disclosure under applicable law.  If the reader of this message is not the 
intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, forwarding, or copying of this communication is 
strictly prohibited.  If you have received this communication in error, please 
notify the sender immediately by return email, and delete the original message 
immediately.

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Nuno Lucas]

On 3/10/07, Nuno Lucas <[EMAIL PROTECTED]> wrote:

On 3/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> > --- [EMAIL PROTECTED] wrote:
> > > Is there something that the SQLite core can do better?
> >
> > Perhaps exclusive locks on journal files would help avoid this problem.
> > Or are the -journal and etilqs_* files supposed to be sharable by other
> > sqlite processes?
> >
>
> They are, at least on unix.  On unix, both files are opened with
> the O_EXCL flag.  How do I do the same thing for windows?

The code does that already. You just pass 0 on the share parameter and
no one can open (or delete) the file until closed. The only difference
to unix is the fact you can't delete a file while open (unless if you
pass the FILE_SHARE_DELETE, which isn't supported by Win9x).

I don't see a problem there. The problem seems to be the journal file
is opened by other programs BEFORE sqlite tries to open it, meaning
sqlite fails to open it in exclusive mode.


Answering to myself again, I'm guessing the programs that don't let
sqlite open the journal files in exclusive mode probably will let it
open in shared mode, so maybe if the journal file is open using the
FILE_SHARE_READ attribute, it will allow both the antivirus and
indexers to also have them open (which I'm guessing open them in read
mode and with sharing enabled), although denying any other program to
open it in write mode.

The only problem may be that sqlite will probably fail to delete them
on the end, but maybe this can be solved with some flag on the journal
file saying it can be ignored if sqlite opens it again, or maybe by
just truncating the file to a zero size.


Regards,
~Nuno Lucas

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[drh]

Dave Dyer <[EMAIL PROTECTED]> wrote:
> >
> >The main purpose of the journal is so that if the program
> >or OS crashes or there is a power failure, once the machine
> >reboots and some other process tries to read the database,
> >the other process can see the journal and roll it back.
> >Private anonymous mapped objects defeat that purpose, it
> >would seem.
> 
> I thought the purpose was to prevent corruption in the main
> database.  If you assume the power fails, or some other
> program disaster occurs, it doesn't really matter if the 
> last transaction was made persistant or not.  It's just
> like the power failed a few seconds sooner.
> 
> So as long as sqlite is still safe if a journal file is deleted
> after a restart, I don't think there's a problem.
> 

The point is that SQLite is NOT safe if the journal file is
deleted after a restart.  In fact, the whole point of the
journal file is to make SQLite safe following program or
OS crashes or power failures.

Sometimes users try to get clever and delete a journal
file after a power failure.  This leads to database
corruption.  See, for example,

   http://www.sqlite.org/cvstrac/tktview?tn=2224

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Nuno Lucas]

On 3/10/07, Nuno Lucas <[EMAIL PROTECTED]> wrote:

On 3/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> They are, at least on unix.  On unix, both files are opened with
> the O_EXCL flag.  How do I do the same thing for windows?

The code does that already. You just pass 0 on the share parameter and
no one can open (or delete) the file until closed. The only difference
to unix is the fact you can't delete a file while open (unless if you
pass the FILE_SHARE_DELETE, which isn't supported by Win9x).


My limited Unix file semantics knowledge got me in error. O_EXCL is
not (as the name seems to imply) used to open a file in exclusive
mode. It only works at creation time to error out if it was already
created (and, from the man page, seems to be broken on NFS
filesystems).

But I believe I got the windows case right, so please just ignore my
unix comparation part.

Regards,
~Nuno Lucas

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[John Stanton]

This is a code snippet for such a function with Windows and Unix.  Even 
here the dreaded NFS raises its ugly head.  The Windows code has worked 
fine, but Windows gurus might find some way to improve it.


  /*Open the file if possible in the appropriate mode.*/
#if IS_WIN32
  mode = GENERIC_READ;
  if (!read_only) mode = mode | GENERIC_WRITE;
  if (exclusive) mode_share = 0;
  else {
mode_share = FILE_SHARE_READ;
if (!read_only) mode_share = mode_share | FILE_SHARE_WRITE;
  }   /*if/else*/

  if (autocreate) mode_create = CREATE_ALWAYS;
  else mode_create = OPEN_EXISTING;

  fd = CreateFile(filename, mode, mode_share, NULL, mode_create,
  FILE_ATTRIBUTE_NORMAL, NULL);
  if (fd == INVALID_HANDLE_VALUE) {
errormet = TRUE; errorflag = IO; errorsub = 'M';
return(TRUE);
  }  /*if*/
#else
  if (read_only) mode = O_RDONLY;
  else mode = O_RDWR;
#if IS_CYGWIN
  mode = mode | O_BINARY;
#endif

  /*Set the mode for exclusive open.*/
#if IS_AIX
  if (exclusive) mode = mode | O_NSHARE;   /*!! Not supported by NFS.*/
#else
  if (exclusive) mode = mode | O_EXCL;
#endif

  /*We may have a PREPARE of an existing file.  Save time by opening
  with truncate.*/
  if (autocreate) mode = mode | O_TRUNC | O_CREAT;

  fd = open(filename, mode, 0666);

  /*A handle value of less then zero indicates that the file was
  neither opened nor created.*/
  if (fd < 0) {
errormet = TRUE; errorflag = IO; errorsub = 'M';
return(TRUE);
  }  /*if*/
#endif

[EMAIL PROTECTED] wrote:

Joe Wilson <[EMAIL PROTECTED]> wrote:


--- [EMAIL PROTECTED] wrote:


Is there something that the SQLite core can do better?


Perhaps exclusive locks on journal files would help avoid this problem.
Or are the -journal and etilqs_* files supposed to be sharable by other 
sqlite processes?





They are, at least on unix.  On unix, both files are opened with
the O_EXCL flag.  How do I do the same thing for windows?
--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[John Stanton]

After I hit  it struck me like a bombshell that the journal has to 
be there for the next startup to perform its complete function so such a 
method would fail.  A virtual memory based object would only provide 
transactional support, not  crash recovery.  Humble pie for breakfast!


OS designers could think about providing a capability of tagging a file 
as private and making it immune to interference from gratuitous activity.


Here is a snippet of Windows and Unix code to create an anonymous 
object.  In this particular concept it is used in an interpreter to 
allocate memory as a more durable alternative to allocating heap area 
with a malloc.


  /*Create a new anonymous mapped virtual memory object.*/
#if IS_WIN32
  hnd = CreateFileMapping((HANDLE)0x, NULL,
  PAGE_READWRITE, 0, newtvsize, NULL);
  newtvar = MapViewOfFile(hnd, FILE_MAP_WRITE, 0, 0, newtvsize);
  if (newtvar == NULL) {   /*Failed*/
/*Fatal error.*/
errormet = TRUE;
spring_trap(PARITY, 'T', ' ', ctxp);
return;
  }  /*if*/
#else
  newtvar = mmap(NULL, newtvsize, (PROT_READ | PROT_WRITE),
 (MAP_PRIVATE | MAP_ANONYMOUS), -1, (off_t)0);
  if ((int)newtvar == -1) {
/*Fatal error.*/
errormet = TRUE;
spring_trap(PARITY, 'T', ' ', ctxp);
return;
  }  /*if*/
#endif

[EMAIL PROTECTED] wrote:

John Stanton <[EMAIL PROTECTED]> wrote:

A suggestion for the journal files would be to make them private 
anonymous mapped objects. 



The main purpose of the journal is so that if the program
or OS crashes or there is a power failure, once the machine
reboots and some other process tries to read the database,
the other process can see the journal and roll it back.
Private anonymous mapped objects defeat that purpose, it
would seem.

On windows, TEMP tables are stored in c:\temp\etilqs_* files.
But on unix, TEMP tables are stored in private, nameless
files that are automatically deleted after a crash.  On unix,
this is accomplished by opening a file then immediately 
unlinking the file while it is still open. Such files disappear

from the filesystem but are still available for I/O.  I don't
think that sort of thing is possible on windows, unless these
"anonymous mapped objects" you speak of might serve the 
purpose.  Where do I find out more about "anonymous mapped

objects" for windows?

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Joe Wilson]

--- Joe Wilson <[EMAIL PROTECTED]> wrote:
> There's also this - CreateFileTransacted():
> 
>  http://msdn2.microsoft.com/en-us/library/aa363859.aspx
> 
> which has the argument:
> 
>  dwShareMode
> ...
> If this parameter is 0 (zero) and CreateFileTransacted succeeds, 
> the object cannot be shared and cannot be opened again until the 
> handle is closed. 
> ...
> The sharing options remain in effect until you close the handle to 
> an object.

Regrettably, CreateFileTransacted() is not a good option as it is new to 
Windows Vista.


 

Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Scott Hess]

On 3/10/07, Joe Wilson <[EMAIL PROTECTED]> wrote:

There's also this - CreateFileTransacted():

 http://msdn2.microsoft.com/en-us/library/aa363859.aspx


Doesn't this require Vista?

-scott

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Joe Wilson]

--- [EMAIL PROTECTED] wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> > --- [EMAIL PROTECTED] wrote:
> > > Is there something that the SQLite core can do better?
> > 
> > Perhaps exclusive locks on journal files would help avoid this problem.
> > Or are the -journal and etilqs_* files supposed to be sharable by other 
> > sqlite processes?
> 
> They are, at least on unix.  On unix, both files are opened with
> the O_EXCL flag.  How do I do the same thing for windows?

I'm just guessing, but LockFileEx() and LOCKFILE_EXCLUSIVE_LOCK might do
the trick:

 http://msdn2.microsoft.com/en-us/library/aa365203.aspx

Unfortunately, the open and exclusive lock combination is not atomic.

There's also this - CreateFileTransacted():

 http://msdn2.microsoft.com/en-us/library/aa363859.aspx

which has the argument:

 dwShareMode
...
If this parameter is 0 (zero) and CreateFileTransacted succeeds, 
the object cannot be shared and cannot be opened again until the 
handle is closed. 
...
The sharing options remain in effect until you close the handle to 
an object.



 

Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Uwe Sander]

Hi,

Am Samstag, 10. März 2007 13:26 schrieb [EMAIL PROTECTED]:
> purpose.  Where do I find out more about "anonymous mapped
> objects" for windows?

ot sure if this is what John wanted to suggest:
http://msdn2.microsoft.com/en-us/ms810613.aspx

Note that you can create a mapping using the systems page file.

Regards
Uwe

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[drh]

Joe Wilson <[EMAIL PROTECTED]> wrote:
> --- [EMAIL PROTECTED] wrote:
> > Is there something that the SQLite core can do better?
> 
> Perhaps exclusive locks on journal files would help avoid this problem.
> Or are the -journal and etilqs_* files supposed to be sharable by other 
> sqlite processes?
> 

They are, at least on unix.  On unix, both files are opened with
the O_EXCL flag.  How do I do the same thing for windows?
--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[drh]

John Stanton <[EMAIL PROTECTED]> wrote:
> A suggestion for the journal files would be to make them private 
> anonymous mapped objects. 

The main purpose of the journal is so that if the program
or OS crashes or there is a power failure, once the machine
reboots and some other process tries to read the database,
the other process can see the journal and roll it back.
Private anonymous mapped objects defeat that purpose, it
would seem.

On windows, TEMP tables are stored in c:\temp\etilqs_* files.
But on unix, TEMP tables are stored in private, nameless
files that are automatically deleted after a crash.  On unix,
this is accomplished by opening a file then immediately 
unlinking the file while it is still open. Such files disappear
from the filesystem but are still available for I/O.  I don't
think that sort of thing is possible on windows, unless these
"anonymous mapped objects" you speak of might serve the 
purpose.  Where do I find out more about "anonymous mapped
objects" for windows?

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[John Stanton]

A suggestion for the journal files would be to make them private 
anonymous mapped objects.  That works on both Unix and Windows and any 
other POSIX compatible system.  Then the journals would be impervious to 
outside interference.


With Unix the mapped object has a fixed size so there would need to be a 
little logic to extend the size.  When I have used this method on Unix I 
have expanded the file exponentially by doubling the size at each 
expansion to minimize expansion cycles.


A bonus of using the mapped object is that i/o is a little faster 
because read and write calls and buffer shadowing are avoided.


Joe Wilson wrote:

--- [EMAIL PROTECTED] wrote:


Is there something that the SQLite core can do better?



Perhaps exclusive locks on journal files would help avoid this problem.
Or are the -journal and etilqs_* files supposed to be sharable by other 
sqlite processes?


 http://www.backupassist.com/BackupAssist/faq.html

 "Basic support - open files locked with a shared lock or no lock are 
 copied and backed up after the main backup. Files with an exclusive 
 lock cannot be copied or backed up. Exclusively locked files are 
 typically SQL Server or Exchange data files."




 

No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 


-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Joe Wilson]

--- [EMAIL PROTECTED] wrote:
> Is there something that the SQLite core can do better?

Perhaps exclusive locks on journal files would help avoid this problem.
Or are the -journal and etilqs_* files supposed to be sharable by other 
sqlite processes?

 http://www.backupassist.com/BackupAssist/faq.html

 "Basic support - open files locked with a shared lock or no lock are 
 copied and backed up after the main backup. Files with an exclusive 
 lock cannot be copied or backed up. Exclusively locked files are 
 typically SQL Server or Exchange data files."



 

No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Dennis Cote]

[EMAIL PROTECTED] wrote:


J. Edgar Hoover
R. Buckminster Fuller
F. Scott Fitzgerald
T. Woodrow Wilson
H. Ross Perot
F. Lee Bailey
C. Everett Koop
L. Ron Hubbard
G. Gordon Liddy
S. Truett Cathy
S. Epatha Merkerson
and so forth...

And I do have a Ph.D. from Duke University :-)

  
So to be accurate we should call you Dr. D. Richard Hipp Ph.D. 

I'm just curious, do you have a preference for a shorter version? 
Richard, DRH, Dr. Hipp, or perhaps Dr. D. or Dr. H? :-)


R. Dennis Cote





-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[drh]

Dave Dyer <[EMAIL PROTECTED]> wrote:
> In general, it's known that daemon processes such as antivirus
> and backup programs can unexpectedly have the journal file open,
> and interfere with sqlite.   If you're deploying sqlite to enduser's
> machines, you can't change this.
> 
> Absent a real solution, I've hacked my copy to retry failed file
> open/close/delete operations after a short delay.
> 

How does your hack improve upon [3200]?

   http://www.sqlite.org/cvstrac/chngview?cn=3200

Is there something that the SQLite core can do better?

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[drh]

Gunnar Roth <[EMAIL PROTECTED]> wrote:
> 
> > Dr Hipp,
> >   
> 
> Nice to see that i am not the only one you read drh as Dr. H. ;-) in 
> fact his name is D. Richard Hipp.
> But i have never seen before the habit to abreviate the first surname.
> 

J. Edgar Hoover
R. Buckminster Fuller
F. Scott Fitzgerald
T. Woodrow Wilson
H. Ross Perot
F. Lee Bailey
C. Everett Koop
L. Ron Hubbard
G. Gordon Liddy
S. Truett Cathy
S. Epatha Merkerson
and so forth...

And I do have a Ph.D. from Duke University :-)

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] journal - "Unable to open the database file"

[RB Smissaert]

Doesn't have to be .db3, but there are certain extension to avoid as posted.

RBS


-Original Message-
From: Allan, Mark [mailto:[EMAIL PROTECTED] 
Sent: 09 March 2007 16:52
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] journal - "Unable to open the database file"


RB Smissaert,
The database file is named .vdb. Is .vdb ok or wrong? Does it have
to be .db3? Or is there just certian extensions I need to avoid?

Dr Hipp,
Currently all journals have been deleted by admin, so I am currently trying
to create another one to find out exactly that information for you.



> -Original Message-
> From: RB Smissaert [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2007 16:40
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] journal - "Unable to open the database file"
> 
> 
> If I remember well this is a problem if you have the 
> extension .db for the
> database file and I think if you change that to something 
> like .db3 then it
> won't happen.
> 
> RBS
> 
> -Original Message-
> From: Allan, Mark [mailto:[EMAIL PROTECTED] 
> Sent: 09 March 2007 16:23
> To: sqlite-users@sqlite.org
> Subject: [sqlite] journal - "Unable to open the database file"
> 
> I have been using SQLite as a replacement for MS Access for 
> use in a PC
> application. It works well but we have been experiencing the following
> problem when the database file is located on a network drive. 
> We are getting
> "Unable to open the database file" when trying to start a new 
> transaction.
> Investigating this it appeared the reason this was happening 
> was that the
> journal file is open by another process and cannot be 
> deleted. SQLite cannot
> delete it and neither can I manually via explorer. After much 
> investiagtion
> with out IT department it looks like the reason this was open is that
> Microsoft Windows Desktop Search (a file indexer program) has 
> opened it. I
> am still unsure why it keeps it open and does not allow for 
> anyone other
> than an admin to delete it. A file may stay in this state for 
> hours before
> mysteriously disappearing of its own accord. If we configure 
> Windows Desktop
> Search to ignore the folder, we do not get (or at least we 
> have not yet got)
> this problem. 
> 
> Basically I would like to:-
> 1) Make this problem known to the community.
> 2) Ask if anyone has experienced anything like this?
> 3) Ask if anyone can offer any advise us as to what we can do 
> to get around
> the problem of a journal file being locked and SQLite cannot 
> delete it?
> Because at the moment if this situation occurs no one can 
> write to that Db
> until the journal file has gone. Which is quite a severe problem...
> 
> Thanks
> 
> Mark
> 
> 
> DISCLAIMER:
> This information and any attachments contained in this email 
> message is
> intended only for the use of the individual or entity to which it is
> addressed and may contain information that is privileged, 
> confidential, and
> exempt from disclosure under applicable law.  If the reader 
> of this message
> is not the intended recipient, or the employee or agent 
> responsible for
> delivering the message to the intended recipient, you are 
> hereby notified
> that any dissemination, distribution, forwarding, or copying of this
> communication is strictly prohibited.  If you have received this
> communication in error, please notify the sender immediately by return
> email, and delete the original message immediately.
> 
> 
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 
> 
> 


DISCLAIMER:
This information and any attachments contained in this email message is
intended only for the use of the individual or entity to which it is
addressed and may contain information that is privileged, confidential, and
exempt from disclosure under applicable law.  If the reader of this message
is not the intended recipient, or the employee or agent responsible for
delivering the message to the intended recipient, you are hereby notified
that any dissemination, distribution, forwarding, or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify the sender immediately by return
email, and delete the original message immediately.


-
To unsubscribe, send email to [EMAIL PROTECTED]

-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] journal - "Unable to open the database file"

[Samuel R. Neff]

Extensions monitored by Windows Desktop Search are stored in the registry:

HKEY_CURRENT_USER\Software\Microsoft\RSSearch\ContentIndexCommon\Filters\Ext
ension

http://addins.msn.com/devguide.aspx

I don't know what the default extension list is.

Also, the wiki has information about how and what extensions affect
performance related to System Restore.  

http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuningWindows

HTH,

Sam


---
We're Hiring! Seeking a passionate developer to join our team building
products. Position is in the Washington D.C. metro area. If interested
contact [EMAIL PROTECTED]
 
-Original Message-
From: Allan, Mark [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 09, 2007 11:52 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] journal - "Unable to open the database file"


RB Smissaert,
The database file is named .vdb. Is .vdb ok or wrong? Does it have
to be .db3? Or is there just certian extensions I need to avoid?

Dr Hipp,
Currently all journals have been deleted by admin, so I am currently trying
to create another one to find out exactly that information for you.



-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[drh]

"Allan, Mark" <[EMAIL PROTECTED]> wrote:
> RB Smissaert,
> The database file is named .vdb. Is .vdb ok or wrong? Does it =
> have to be .db3? Or is there just certian extensions I need to avoid?
> 
> Dr Hipp,
> Currently all journals have been deleted by admin, so I am currently =
> trying to create another one to find out exactly that information for =
> you.
> 

Thanks.  Here's how you might go about creating a hot journal:

   *  Open the database file.
   *  Run the BEGIN command.
   *  Make some change to the database but do not COMMIT.
   *  call assert(0) or do something else to make your
  program crash without shutting down or closing the
  database connection.

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[Gunnar Roth]

Allan, Mark schrieb:

RB Smissaert,
The database file is named .vdb. Is .vdb ok or wrong? Does it have to 
be .db3? Or is there just certian extensions I need to avoid?

  

I  quote from http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuningWindows

"Be *VERY, VERY* careful what you name your database, especially the 
/extension/


For example, if you give all your databases the extension .sdb (SQLite 
Database, nice name hey? I thought so when I choose it anyway...) you 
discover that the SDB extension is already associated with APPFIX PACKAGES.


Now, here is the cute part, APPFIX is an executable/package that Windows 
XP recognizes, and it will, (emphasis mine) *ADD THE DATABASE TO THE 
SYSTEM RESTORE FUNCTIONALITY*


This means, stay with me here, every time you write ANYTHING to the 
database, the Windows XP system thinks a bloody executable has changed 
and copies your ENTIRE 800 meg database to the system restore directory


I recommend something like DB or DAT.

The entire list of system restore-monitored filename extensions can be 
found at: 
¤http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sr/sr/monitored_file_extensions.asp; 





Dr Hipp,
  


Nice to see that i am not the only one you read drh as Dr. H. ;-) in 
fact his name is D. Richard Hipp.

But i have never seen before the habit to abreviate the first surname.

Regards,
Gunnar



-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] journal - "Unable to open the database file"

[Allan, Mark]

RB Smissaert,
The database file is named .vdb. Is .vdb ok or wrong? Does it have to 
be .db3? Or is there just certian extensions I need to avoid?

Dr Hipp,
Currently all journals have been deleted by admin, so I am currently trying to 
create another one to find out exactly that information for you.



> -Original Message-
> From: RB Smissaert [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2007 16:40
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] journal - "Unable to open the database file"
> 
> 
> If I remember well this is a problem if you have the 
> extension .db for the
> database file and I think if you change that to something 
> like .db3 then it
> won't happen.
> 
> RBS
> 
> -Original Message-
> From: Allan, Mark [mailto:[EMAIL PROTECTED] 
> Sent: 09 March 2007 16:23
> To: sqlite-users@sqlite.org
> Subject: [sqlite] journal - "Unable to open the database file"
> 
> I have been using SQLite as a replacement for MS Access for 
> use in a PC
> application. It works well but we have been experiencing the following
> problem when the database file is located on a network drive. 
> We are getting
> "Unable to open the database file" when trying to start a new 
> transaction.
> Investigating this it appeared the reason this was happening 
> was that the
> journal file is open by another process and cannot be 
> deleted. SQLite cannot
> delete it and neither can I manually via explorer. After much 
> investiagtion
> with out IT department it looks like the reason this was open is that
> Microsoft Windows Desktop Search (a file indexer program) has 
> opened it. I
> am still unsure why it keeps it open and does not allow for 
> anyone other
> than an admin to delete it. A file may stay in this state for 
> hours before
> mysteriously disappearing of its own accord. If we configure 
> Windows Desktop
> Search to ignore the folder, we do not get (or at least we 
> have not yet got)
> this problem. 
> 
> Basically I would like to:-
> 1) Make this problem known to the community.
> 2) Ask if anyone has experienced anything like this?
> 3) Ask if anyone can offer any advise us as to what we can do 
> to get around
> the problem of a journal file being locked and SQLite cannot 
> delete it?
> Because at the moment if this situation occurs no one can 
> write to that Db
> until the journal file has gone. Which is quite a severe problem...
> 
> Thanks
> 
> Mark
> 
> 
> DISCLAIMER:
> This information and any attachments contained in this email 
> message is
> intended only for the use of the individual or entity to which it is
> addressed and may contain information that is privileged, 
> confidential, and
> exempt from disclosure under applicable law.  If the reader 
> of this message
> is not the intended recipient, or the employee or agent 
> responsible for
> delivering the message to the intended recipient, you are 
> hereby notified
> that any dissemination, distribution, forwarding, or copying of this
> communication is strictly prohibited.  If you have received this
> communication in error, please notify the sender immediately by return
> email, and delete the original message immediately.
> 
> 
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 
> 
> 


DISCLAIMER:
This information and any attachments contained in this email message is 
intended only for the use of the individual or entity to which it is addressed 
and may contain information that is privileged, confidential, and exempt from 
disclosure under applicable law.  If the reader of this message is not the 
intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, forwarding, or copying of this communication is 
strictly prohibited.  If you have received this communication in error, please 
notify the sender immediately by return email, and delete the original message 
immediately.

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] journal - "Unable to open the database file"

[RB Smissaert]

If I remember well this is a problem if you have the extension .db for the
database file and I think if you change that to something like .db3 then it
won't happen.

RBS

-Original Message-
From: Allan, Mark [mailto:[EMAIL PROTECTED] 
Sent: 09 March 2007 16:23
To: sqlite-users@sqlite.org
Subject: [sqlite] journal - "Unable to open the database file"

I have been using SQLite as a replacement for MS Access for use in a PC
application. It works well but we have been experiencing the following
problem when the database file is located on a network drive. We are getting
"Unable to open the database file" when trying to start a new transaction.
Investigating this it appeared the reason this was happening was that the
journal file is open by another process and cannot be deleted. SQLite cannot
delete it and neither can I manually via explorer. After much investiagtion
with out IT department it looks like the reason this was open is that
Microsoft Windows Desktop Search (a file indexer program) has opened it. I
am still unsure why it keeps it open and does not allow for anyone other
than an admin to delete it. A file may stay in this state for hours before
mysteriously disappearing of its own accord. If we configure Windows Desktop
Search to ignore the folder, we do not get (or at least we have not yet got)
this problem. 

Basically I would like to:-
1) Make this problem known to the community.
2) Ask if anyone has experienced anything like this?
3) Ask if anyone can offer any advise us as to what we can do to get around
the problem of a journal file being locked and SQLite cannot delete it?
Because at the moment if this situation occurs no one can write to that Db
until the journal file has gone. Which is quite a severe problem...

Thanks

Mark


DISCLAIMER:
This information and any attachments contained in this email message is
intended only for the use of the individual or entity to which it is
addressed and may contain information that is privileged, confidential, and
exempt from disclosure under applicable law.  If the reader of this message
is not the intended recipient, or the employee or agent responsible for
delivering the message to the intended recipient, you are hereby notified
that any dissemination, distribution, forwarding, or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify the sender immediately by return
email, and delete the original message immediately.



-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] journal - "Unable to open the database file"

[drh]

"Allan, Mark" <[EMAIL PROTECTED]> wrote:
> 3) Ask if anyone can offer any advise us as to what we can do 
> to get around the problem of a journal file being locked and 
> SQLite cannot delete it? Because at the moment if this situation 
> occurs no one can write to that Db until the journal file has 
> gone. Which is quite a severe problem...
> 

While Windows Desktop Search has the journal file open, is the
journal file read only?  Is it possible to change the content
of the file or even truncate the file to zero length as long as
the file is not deleted?

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-