> There is a better workaround: get the code from the .dump command of sqlite3
> utility and use it... 
> it creates a fresh copy of your database like using
> sqlite3 dbold .dump | sqlite3 newdb (not sure about the syntax, thereĀ“s a
> example of this
> case on internet)

This will always work and is safe, but it's very slow on large databases 
with tables with many indexes. You also lose page_size and other pragma 
settings on your database.

> I think a possible solution is to lock the database with a "BEGIN EXCLUSIVE"
> statement and then copy the database file.

This will also work on UNIX - but only if the file copy is done via a 
different(!!) UNIX process. 

If you try to make the copy via the same process - even by open()ing a new
file descriptor while the sqlite3 database is in use, you can end up with 
a corrupt database.

The only safe way to perform an exclusive-lock-copy-db-file-in-same-process
is to actually use the same file descriptor of an already open database, 
perform read()s on that fd (and obviously not close() it).
So if you wish to do such a thing, you'd either need to expose the file
descriptor of the database, or have sqlite provide a new API function to 
safely copy a database that has active sqlite3 connection(s).


Ticket 2665: Dissapearing exclusive lock when DB is copied...

"2007-Sep-25 18:32:06 by drh:
On unix, when you close a file, all locks on that file held by the same process 
are cleared - even
locks that were created by separate file descriptors. You are probably closing 
the file at the
conclusion of your copy, which is clearing the locks."

Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.

To unsubscribe, send email to [EMAIL PROTECTED]

Reply via email to