Hello, Could you open a memory database and then attach the disk based database. Create the tables in the memory database and copy the rows from the disk based into memory. Once done detach the database , delete it from disk . Then create a disk based database , close it and attach it to the memory database and then do the reverse but only with the rows you want.
might be worth a try regards Greg O ----- Original Message ----- From: "Jakub Adamek" <[EMAIL PROTECTED]> To: "D. Richard Hipp" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, February 17, 2004 7:04 PM Subject: Re: [sqlite] Database Full! > Hello, > it seems to me the solution would be: Create a special small file just > to protect some disc space. If you lack on disc space, delete the > protecting file (and hope nobody will steal the disc space inbetween) > and delete some records. Than again create the protecting file. > Obviously, in a live system this may fail ... > > Jakub > > D. Richard Hipp wrote: > > > Benoit Gantaume wrote: > > > >> Hi, > >> I am trying to handle a problem that occurs when the disk is full: > >> when i try to insert, that return SQLITE_FULL. > >> > >> Ok. > >> > >> There is not problem to get some elements from the database. > >> > >> Then I try to remove some elements... > >> But that returns SQLITE_BUSY! > >> > >> I have tryed to stop all operation with: sqlite_interrupt(this->cdb); > >> But it seems to have no effect! > >> > >> How can I free the database so that I can remove some elements from it? > >> > > > > > > DELETE requires some temporary disk space for the rollback journal. > > So if your disk is full, you cannot delete. > > > > Furthermore, just doing some DELETEs does not reduce the size of the > > database file. DELETE just adds some 1024-byte blocks of the file to > > an internal freelist where they can be reused later for other purposes. > > To actually reduce the size of the database file, you need to run > > VACUUM after you DELETE. VACUUM requires temporary disk space that > > is a little over 2x larger than the size of the original database. > > So (ironically) if you are low on disk space, VACUUM probably will > > not run. > > > > So, as you can see, it is difficult to get SQLite to run when you are > > low on disk space. Your best solution is to get a bigger disk. > > > > A bigger disk drive is the right answer for your desktop, but for > > an embedded solution (with perhaps a few MB of flash disk) that is > > not practical. That problem has been brought to my attention and > > work is underway to make SQLite behave better in a low diskspace > > environment. Unfortunately, the changes to accomplish this will not > > be available in the public version of SQLite for a least 3 more months > > and probably longer than that. Sorry. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
