Re: [sqlite] Database full error?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/10/11 14:03, PA Newsgroups wrote: > Is there anything else that could cause this error? It's on a Windows > computer if that makes any difference. SQLite code has a tendency to report virtually any error involving write calls as the disk being full. Also be aware that the write may not be to the main database but could be elsewhere (eg temporary space while sorting, journals etc). The easiest way to find out exactly what happened is to use the Process Monitor tool from Sysinternals (now owned by Microsoft). Then look to see what error happened with which file. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6fQpoACgkQmOOfHg372QT70wCfQ3jK0F73O5PGg5dPaL+moKl1 4aUAn1zAWHWVqOciS4VAoYnhlUvKuswd =2/Ya -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Database full error?
I have a customer with a database whose file size is about 39GB. He's getting error 13 (database or disk is full) on an insert. My app sets the page size to 4096, but even if it was the default, this error shouldn't happen until it's around 4TB in size based on what I read the default SQLITE_MAX_PAGE_COUNT value is. There is plenty of free disk space on the drive, and other databases are being successfully written to in that same folder, so I don't think it's a rights issue. Is there anything else that could cause this error? It's on a Windows computer if that makes any difference. Doug ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] "database full" errors
what would cause this error? I have a few users reporting it, all with different database file sizes. is there a limit on row counts in 3.x ? -- Cory Nelson http://www.int64.org
RE: [sqlite] Database Full!
The only really safe way to compress the database would be to use an
incremental procedure similar to the familiar {to most :-) Windoze
"Defragment" disk utility. The process needs to be reasonably fail safe and
disk miserly. Until this feature is enhanced, one should remain vigilant as
to database size as one could quickly paint one's self into a corner in some
limited storage and embedded environments.
Fred
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 7:42 AM
To: Greg Obleshchuk
Cc: [EMAIL PROTECTED]
Subject: Re: [sqlite] Database Full!
"Greg Obleshchuk" <[EMAIL PROTECTED]> writes:
> 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 .
If the machine crashes at this point, you're up that well known creek
without
a paddle... I hope you have good backups. :-)
> 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.
Derrell
-
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]
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]
Re: [sqlite] Database Full!
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. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] Database Full!
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? Thanks. __ Benoit GantaumeDmailer vous facilite la gestion de linformation. Phone :Fax :Email : +33 (0) 4 91 29 32 81+33 (0) 4 91 76 39 27[EMAIL PROTECTED] DISCLAIMER:The integrity of this message cannot be guaranteed on the Internet. Dmailer cannot therefore be held responsible for the contents of this e-mail. This e-mail may contain proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Dmailer Ce message et toutes les pièces jointes sont confidentiels et établis à lintention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible daltération. Dmailer décline toute responsabilité au titre de ce message sil a été altéré, déformé, falsifié ou encore diffusé sans autorisation.
