> 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). See: Ticket 2665: Dissapearing exclusive lock when DB is copied... http://www.sqlite.org/cvstrac/tktview?tn=2665 "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. http://autos.yahoo.com/index.html ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
