> just a few minutes ago I ran a VACUUM on a DB file and the size before
> was 2089610240 and afterwards 2135066624. Is this normal?
>
>
If you have a copy of the old db and new db, can you check the results on
both databases of the following pragmas:
PRAGMA freelist_count;
PRAGMA integrity_check;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi there,
just a few minutes ago I ran a VACUUM on a DB file and the size before
was 2089610240 and afterwards 2135066624. Is this normal?
Thanks,
// Oliver
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
iQEcBAEBCAAGBQJMk/T6AAoJE
On Tuesday, August 03, 2010 2:15 PM, Simon Slavin wrote:
> You can't attach files to messages to this forum. This is done
> intentionally to stop the posts getting unacceptably long (people
> with problems tend to attach their entire source code).
Cunning! Ok, in that case, if anyone is interes
On 3 Aug 2010, at 1:14pm, Andy Gibbs wrote:
> On Tuesday, August 03, 2010 2:09 PM, Andy Gibbs wrote:
>
>> I've attached a patch to this email as a follow-up to this suggestion.
>
> Sorry, I think I forgot to attach the patch file. Hopefully its attached
> this time!
You can't attach files to
On Tuesday, August 03, 2010 2:09 PM, Andy Gibbs wrote:
I've attached a patch to this email as a follow-up to this suggestion.
Sorry, I think I forgot to attach the patch file. Hopefully its attached
this time!
Andy
___
sqlite-users mailing list
s
On Monday, August 02, 2010 4:25 AM, Nikolaus Rath wrote:
Hi,
Could someone clarify to me how the VACUUM command works if WAL is
enabled?
I would like to compact my database, but I am note sure if I should:
1) Run PRAGMA wal_checkpoint to get all outstanding commits into the
database file an
Hi,
Could someone clarify to me how the VACUUM command works if WAL is
enabled?
I would like to compact my database, but I am note sure if I should:
1) Run PRAGMA wal_checkpoint to get all outstanding commits into the
database file and then VACUUM to compact the database file,
or should I
2
On Mon, Jul 26, 2010 at 12:28:42PM -0700, Taras Glek scratched on the wall:
> Hi,
> I noticed an interesting disk-space behavior with VACUUM. If I vacuum my
> places.sqlite(Firefox database), it's 49mb. If then copy my 2 biggest
> tables with
> CREATE table2 as select * from orig_table; drop
On Mon, Jul 26, 2010 at 3:28 PM, Taras Glek wrote:
> Hi,
> I noticed an interesting disk-space behavior with VACUUM. If I vacuum my
> places.sqlite(Firefox database), it's 49mb. If then copy my 2 biggest
> tables with
> CREATE table2 as select * from orig_table; drop table ; alter table2
> rena
On Mon, Jul 26, 2010 at 11:28 PM, Taras Glek wrote:
> Hi,
> I noticed an interesting disk-space behavior with VACUUM. If I vacuum my
> places.sqlite(Firefox database), it's 49mb. ...
> ...
> Then vacuum, the db becomes 24mb.
>
Taras,
49 almost equal to 24*2. Can it be related to some encoding c
Hi,
I noticed an interesting disk-space behavior with VACUUM. If I vacuum my
places.sqlite(Firefox database), it's 49mb. If then copy my 2 biggest
tables with
CREATE table2 as select * from orig_table; drop table ; alter table2
rename to table;
Then vacuum, the db becomes 24mb. The same beh
> First, I'm sure it is nearly impossible to do this as a
> guaranteed, atomic operation on most OSes and filesystems. ...
>
> Second, if this is meant to look like a cleanup operation on the
> original file, the original file (including any filesystem meta-data)
> should be kept in-tact. ..
On Tue, Mar 16, 2010 at 06:18:13PM +0300, Max Vlasov scratched on the wall:
> When I read the comments it was obvious that the algorithm uses very simple
> approach:
> Attach blank database, copy all data, detach, rename. Sure I might be
> wrong in details, but generally it looks like this.
W
> So the question is what is so special about sqlite3RunVacuum that it needs
> more space than a simple emulation of its actions?
I believe renaming of the file cannot be atomic. So in case of OS
crash you can be in situation without database at all - no old and no
new. Also deleting of old file c
> This means that to VACUUM a SQLite database of size X, you need at
> least 2X of _additional_ free disk space available. That seems rather
> wasteful, just looking at it as a SQLite user. Although
> programmatically there may be reasons for it that I'm not aware of.
>
>
Hmm, did some research,
On Mon, Mar 15, 2010 at 11:18 AM, Scott Hess wrote:
> AFAICT, the operation to copy the pages back _is_ journaled, and the
> journal will get any pages which are overwritten in the front of the
> main database. If the initial database has half of the pages used, it
> seems like the journal could
On Mon, Mar 15, 2010 at 11:18:32AM -0800, Scott Hess scratched on the wall:
> On Sun, Mar 14, 2010 at 5:18 PM, Jay A. Kreibich wrote:
> > ?While I have not tested this, I was under the impression that the
> > ?journal file is very very small, as no modifications are made to the
> > ?database, oth
On Sun, Mar 14, 2010 at 5:18 PM, Jay A. Kreibich wrote:
> On Sun, Mar 14, 2010 at 07:19:59PM -0400, Matthew L. Creech scratched on the
> wall:
>> I have a SQLite database with one large table, and I'd like to shrink
>> the size of that table to free up space in the filesystem. My problem
>> is t
On Mar 14, 2010, at 7:19 PM, Matthew L. Creech wrote:
> Hi,
>
> I have a SQLite database with one large table, and I'd like to shrink
> the size of that table to free up space in the filesystem.
>
> I'm finding that it needs a full 100 MB for the journal, even
> though once the VACUUM succeeds th
On Mon, Mar 15, 2010 at 2:11 AM, Matthew L. Creech wrote:
>
> I'll give this a try tomorrow on a real device with journaling off,
> and see how much space it uses in /tmp with journaling turned off.
>
I ran some tests on a real device with a real database, and got the
following results:
===
ot; for instructions
Enter SQL statements terminated with a ";"
sqlite> SELECT count() FROM val_table;
663552
sqlite> DELETE FROM val_table WHERE idx < 60;
sqlite> SELECT count() FROM val_table;
51840
sqlite> VACUUM;
In another shell, I've got a script monitoring the
On Sun, Mar 14, 2010 at 07:19:59PM -0400, Matthew L. Creech scratched on the
wall:
> Hi,
>
> I have a SQLite database with one large table, and I'd like to shrink
> the size of that table to free up space in the filesystem. My problem
> is that the database is (for example) 100 MB, and I have 80
Hi,
I have a SQLite database with one large table, and I'd like to shrink
the size of that table to free up space in the filesystem. My problem
is that the database is (for example) 100 MB, and I have 80 MB of free
filesystem space. I figured that I could DELETE, say, half of the
records from th
Richard Dauben wrote:
> Hopefully a quick Vacuum question I want to vacuum my sqlite3 database
> from an Objective C program but have not been able to find the necessary
> routine or statement. What is the proper syntax?
>
Gimme a V
Gimme an A
Gimme a C
Gimme a U
Gimme a U
Gimme an M
It'
Hopefully a quick Vacuum question I want to vacuum my sqlite3 database
from an Objective C program but have not been able to find the necessary
routine or statement. What is the proper syntax?
___
sqlite-users mailing list
sqlite-users@sqlite.org
ht
manohar s wrote:
> Yes, the solution you suggested is working fine. But can't we change this
> through SQLite?
>
>
You can set the location SQLite will use for temporary files using
pragma commands. See pragma_temp_store and pragma_temp_store_directory
at http://www.sqlite.org/pragma.html#modi
Also, In linux whether these temporary files are created while vacuuming? If
yes, can you tell me where will this be created?
manohar
On Tue, Mar 17, 2009 at 6:20 PM, manohar s wrote:
> Yes, the solution you suggested is working fine. But can't we change this
> through SQLite?
>
> Thanks and Re
Yes, the solution you suggested is working fine. But can't we change this
through SQLite?
Thanks and Regards,
Manohar.S
On Wed, Mar 11, 2009 at 12:44 PM, Mihai Limbasan wrote:
> manohar s wrote:
> > Hi,
> > I am trying to execute "PRAGMA page_size=4096; Vacuum;" on a SQLite
> DB(Size
> > 1.5 GB
manohar s wrote:
> Hi,
> I am trying to execute "PRAGMA page_size=4096; Vacuum;" on a SQLite DB(Size
> 1.5 GB), On a drive which has 9 GB free space (But my C: has 150 MB free is
> this an issue?). But it is failing with "SQL Error:Database or disk is full"
> error everytime. SQLite version: 3.6.1
Hi,
I am trying to execute "PRAGMA page_size=4096; Vacuum;" on a SQLite DB(Size
1.5 GB), On a drive which has 9 GB free space (But my C: has 150 MB free is
this an issue?). But it is failing with "SQL Error:Database or disk is full"
error everytime. SQLite version: 3.6.11.
1) Am I missing anythin
On Mar 1, 2009, at 4:03 PM, Dair Grant wrote:
>
> Hi,
>
> Are there any circumstances in which a vacuum could corrupt a
> database?
>
VACUUM should never corrupt a database under any circumstances.
If you have a reproducible corruption scenario, please contact me or
one of the other SQLite
Hi,
Are there any circumstances in which a vacuum could corrupt a database?
I am storing about 30 images in an SQLite database, where each row
contains a couple of integers and a BLOB of data (average size 80Kb).
There are a some indices on the integer columns, and the final database is
aro
D. Richard Hipp wrote:
>> Though if your db has reached a steady-state size you might consider
>> running a VACUUM just *before* deleting the records, to avoid peaks
>> persisting ... and even then (say) every *other* week.
>> Just a thought !
>>
> VACUUM also defragments a database file which
On Oct 27, 2008, at 7:34 AM, MikeW wrote:
> Mohit Sindhwani <[EMAIL PROTECTED]> writes:
>
>>
>> Cory Nelson wrote:
>>> vacuum shrinks the database size by removing empty pages. sqlite
>>> will
>>> normally reuse empty pages - so vacuum is only useful if you don't
>>> plan to insert anything el
Mohit Sindhwani <[EMAIL PROTECTED]> writes:
>
> Cory Nelson wrote:
> > vacuum shrinks the database size by removing empty pages. sqlite will
> > normally reuse empty pages - so vacuum is only useful if you don't
> > plan to insert anything else, otherwise it will be slower.
> >
>
> Thanks Co
Cory Nelson wrote:
> On Sun, Oct 26, 2008 at 8:17 PM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote:
>
>> I'm setting to to delete a bunch of old records ever 2 weeks in a cron
>> job and initially I just wanted to do delete * from table where
>> datetime(created_on, 'localtime') < some_date.
>>
>>
On Sun, Oct 26, 2008 at 8:17 PM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote:
> I'm setting to to delete a bunch of old records ever 2 weeks in a cron
> job and initially I just wanted to do delete * from table where
> datetime(created_on, 'localtime') < some_date.
>
> Then, I remembered about vacuum
I'm setting to to delete a bunch of old records ever 2 weeks in a cron
job and initially I just wanted to do delete * from table where
datetime(created_on, 'localtime') < some_date.
Then, I remembered about vacuum - do I need to vacuum the database
whenever I delete the records? Should I just
OK, the mystery has been solved: didn't notice, that disk just reached
100% usage... :D
--
pozdrawiam / regards
Zbigniew Baniewski
___
sqlite-users mailing list
sqlite-users
On Sun, Sep 21, 2008 at 12:26:32AM +0100, [EMAIL PROTECTED] wrote:
> You know what disk IO error means, right? Run scandisk
No, the disk is OK.
> and try dumping the database and restoring it to a new file.
Yes, I'm aware, that one can just create the database anew - but I was
asking, why VACU
A 25mb file is nothing for SQLite; I vacuumed a 270mb test database a
few hours ago with no problems.
You know what disk IO error means, right? Run scandisk and try
dumping the database and restoring it to a new file.
On 9/21/08, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> It seems, it's not
It seems, it's not possible to VACUUM a bit larger file? I tried to VACUUM
a database file of 25 MB size, containing 75000 records (about 20 fields
each). Unfortunately, each VACUUM attempt is interrupted with message:
SQL error: disk I/O error
No VACUUM allowed for such size?
Linux 2.6.26, SQLi
.db.malo
SQLite version 3.5.6
Enter ".help" for instructions
sqlite> pragma integrity_check;
*** in database main ***
Main freelist: 1 of 1 pages missing from overflow list starting at 0
wrong # of entries in index fifo_referencias
wrong # of entries in index sqlite_autoindex_fifo_fis_1
sq
DRH,
I guess, the question being asked is twofold.
Should there be an error returned at all ? Or if there is an error,
wouldn't SQLITE_BUSY be more appropriate... So the users app could attempt a
retry?
Since there is an error, it seems that the error message is not the same as
ìì ìê° sqlite-users@sqlite.org ë¡ë¶í° ì¤ë ë©ì¼ì ìì ì ê±°ë¶íììµëë¤.
_
--- Begin Message ---
sqlite-users@sqlite.org wrote:
> Hi all,
>
> Hopefully you can help, while running sqlite version 3.5.5
>
> Two seperate thr
sqlite-users@sqlite.org wrote:
> Hi all,
>
> Hopefully you can help, while running sqlite version 3.5.5
>
> Two seperate threads each attempt to run a vacuum command against the same
> db. Each thread has an independent connnection to the db.
>
> One thread succeeds and the other gets a retu
ìì ìê° sqlite-users@sqlite.org ë¡ë¶í° ì¤ë ë©ì¼ì ìì ì ê±°ë¶íììµëë¤.
_
--- Begin Message ---
Hi all,
Hopefully you can help, while running sqlite version 3.5.5
Two seperate threads each attempt to run a vacuum comman
Hi all,
Hopefully you can help, while running sqlite version 3.5.5
Two seperate threads each attempt to run a vacuum command against the same db.
Each thread has an independent connnection to the db.
One thread succeeds and the other gets a return code of 1 (SQLITE_ERROR) from
sqlite3_step
Hello,
I recently got some debug logs from my users that indicate problems
with VACUUM command. The error message is:
SQL logic error or missing database (1).
This is using the latest SQLite (3.4.1) Windows DLL.
I tried to rule out my coding mistakes, at the moment of the problem
there is only
JP <[EMAIL PROTECTED]> wrote:
> I don't know if it is a bug or works as designed, but, should VACUUM be
> changing the format of the DB?
>
> I created a database with sqlite 3.2.7, and after a VACUUM in sqlite
> 3.3.6 I could no longer open it in the older program - error message #1,
> unsuppor
I don't know if it is a bug or works as designed, but, should VACUUM be
changing the format of the DB?
I created a database with sqlite 3.2.7, and after a VACUUM in sqlite
3.3.6 I could no longer open it in the older program - error message #1,
unsupported file format.
jp
Hi all,
I want to do a vacuum on my table. Can any one tell me
whether the below statement is the valid syntax for the vacuum command.
How can we make sure that the command is really executing or not. Will
there be any time difference if we do the vacuum for a table? I tried
inserting
Persson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 02, 2006 10:33 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Vacuum Command
I am new to SQLITE but in some other database vacuum want to have full
controll test with
Transaction as
BEGIN EXCLUSIVE TRANSACTION test
VACUUM [tableName]
END
(causing a SCHEMA_CHANGE)
and then add this table back into the db?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 02, 2006 10:08 AM
To: George Mavroudes
Subject: Re: [sqlite] Vacuum Command
GM> hi,
GM> - I am pretty new to SQLITE
: [sqlite] Vacuum Command
I am new to SQLITE but in some other database vacuum want to have full
controll test with
Transaction as
BEGIN EXCLUSIVE TRANSACTION test
VACUUM [tableName]
END TRANSACTION test
// Anders
George Mavroudes skrev:
> Sorry for the omission and thanks for the qu
George Mavroudes wrote:
If I delete all records from a [tableName] and then execute the VACUUM
command, will this temporarily delete the table (causing a SCHEMA_CHANGE)
and then add this table back into the db?
George,
Yes, SQLite has an optimization which replaces a delete without a where
: [sqlite] Vacuum Command
GM> hi,
GM> - I am pretty new to SQLITE and I am having a problem with the
GM> following sequence of commands:
GM> - DELETE FROM [tableName]
GM> - VACUUM [tableName]
GM> The project I am working on has multiple threads Reading
GM> hi,
GM> - I am pretty new to SQLITE and I am having a problem with the
GM> following sequence of commands:
GM> - DELETE FROM [tableName]
GM> - VACUUM [tableName]
GM> The project I am working on has multiple threads Reading / Writing to this
GM> table and other t
hi,
- I am pretty new to SQLITE and I am having a problem with the
following sequence of commands:
- DELETE FROM [tableName]
- VACUUM [tableName]
The project I am working on has multiple threads Reading / Writing to this
table and other tables, and after inserti
ed an
autovacuum.
Robert
> -Original Message-
> From: Tobias_Rundström [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 22, 2006 3:01 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Vacuum slow
>
>
> El 02-03-2006, a las 13:35, [EMAIL PROTECTED] esc
El 02-03-2006, a las 13:35, [EMAIL PROTECTED] escribió:
The VACUUM command does something very much like this:
sqlite3 olddb .dump | sqlite3 newdb; mv newdb olddb
I say "much like" the above because there are some
important differences. The VACUUM command transfers
the data from the old a
-Ursprüngliche Nachricht-
Von: Jay Sprenkle [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 2. März 2006 17:21
An: sqlite-users@sqlite.org
Betreff: Re: [sqlite] Vacuum slow
> But I wonder :
>
> if I have a db ~ 1gb and I delete all the data in the tables ( db is
> than
"Eggert, Henri" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I use sqlite 3.3.4 and I am very happy with it - it is very fast.
>
> But I wonder :
>
> if I have a db ~ 1gb and I delete all the data in the tables ( db is
> than nearly empty )
> Issuing a vacuum command takes a long time ( several min
> But I wonder :
>
> if I have a db ~ 1gb and I delete all the data in the tables ( db is
> than nearly empty )
> Issuing a vacuum command takes a long time ( several minutes ).
> Why ?
> Is there a way to "vacuum" faster ?
We found that vacuuming the database was also slow. We no longer vaccum
Hello Jay,
Thursday, March 2, 2006, 11:20:50 AM, you wrote:
>> But I wonder :
>>
>> if I have a db ~ 1gb and I delete all the data in the tables ( db is
>> than nearly empty )
>> Issuing a vacuum command takes a long time ( several minutes ).
>> Why ?
>> Is there a way to "vacuum" faster ?
JS> I
> But I wonder :
>
> if I have a db ~ 1gb and I delete all the data in the tables ( db is
> than nearly empty )
> Issuing a vacuum command takes a long time ( several minutes ).
> Why ?
> Is there a way to "vacuum" faster ?
If you delete ALL the data you can just delete the database file
then crea
Hi all,
I use sqlite 3.3.4 and I am very happy with it - it is very fast.
But I wonder :
if I have a db ~ 1gb and I delete all the data in the tables ( db is
than nearly empty )
Issuing a vacuum command takes a long time ( several minutes ).
Why ?
Is there a way to "vacuum" faster ?
Thank's f
On Fri, 2005-04-15 at 09:53 +0200, Eggert Henri wrote:
> Hi sqlite-users :)
>
> Deleting records in a sqlite db leaves unused blocks which are free'd by
> vacuum.
>
> Whithout doing vacuum , does inserting new records use the wasted space
> , or remains wasted space for ever.
>
Unused space is
Hi sqlite-users :)
Deleting records in a sqlite db leaves unused blocks which are free'd by
vacuum.
Whithout doing vacuum , does inserting new records use the wasted space
, or remains wasted space for ever.
Thanks a lot for any help!
With kind regards
Henri
D. Richard Hipp wrote:
Your database schema became corrupted. I do not know how it happened.
I am unable to reproduce the problem. Without additional information
there is nothing more I can do.
What additional information can I provide?
Is there any chance at all to recover any of the data?
--
On Mon, 2005-03-14 at 10:51 -0500, Mitchell Vincent wrote:
> Mitchell Vincent wrote:
> > D. Richard Hipp wrote:
> >>
> >> Can you tell me what the original schema is?
> >
> >
> > Replied in private with the schema. I'm also happy to send the custom
> > compiled DLL and the database if you need i
Mitchell Vincent wrote:
D. Richard Hipp wrote:
Can you tell me what the original schema is?
Replied in private with the schema. I'm also happy to send the custom
compiled DLL and the database if you need it.
Thanks!!!
Any additional thoughts on this? I'm happy to provide any additional
informat
D. Richard Hipp wrote:
On Thu, 2005-03-10 at 18:20 -0500, Mitchell Vincent wrote:
D. Richard Hipp wrote:
Were the blank lines in the original schema, or did they get
inserted? Can you reproduce this problem?
The blank lines got inserted.
I can't reproduce this,
Can you tell me what the original s
On Thu, 2005-03-10 at 18:20 -0500, Mitchell Vincent wrote:
> D. Richard Hipp wrote:
> >
> > Were the blank lines in the original schema, or did they get
> > inserted? Can you reproduce this problem?
>
> The blank lines got inserted.
>
> I can't reproduce this,
Can you tell me what the original
D. Richard Hipp wrote:
Were the blank lines in the original schema, or did they get
inserted? Can you reproduce this problem?
The blank lines got inserted.
I can't reproduce this, no, it is straight from a customer. He insists
that he is the only person accessing the database and that it happened
On Thu, 2005-03-10 at 17:23 -0500, Mitchell Vincent wrote:
> It looks like one of the tables in the db is corrupted, I see this in a
> .dump :
>
> CREATE TABLE payments(payment_id INTEGER PRIMARY KEY,
>
> invoice_id int4,
>
> customer_id int4,
>
> created timestamp,
>
> payment_type varchar,
D. Richard Hipp wrote:
On Thu, 2005-03-10 at 16:37 -0500, Mitchell Vincent wrote:
sqlite> vacuum;
SQL error: near "varchaÃ": syntax error
sqlite>
These databases had been made with an earlier version of SQLite.. Ideas?
Not much to go on
I thought maybe it had something to do
On Thu, 2005-03-10 at 16:37 -0500, Mitchell Vincent wrote:
> sqlite> vacuum;
> SQL error: near "varchaÃ": syntax error
> sqlite>
>
> These databases had been made with an earlier version of SQLite.. Ideas?
>
Not much to go on
--
D. Richard Hipp <[EMAIL PROTECTED]>
sqlite> vacuum;
SQL error: near "varchaä": syntax error
sqlite>
These databases had been made with an earlier version of SQLite.. Ideas?
--
- Mitchell Vincent
- kBilling - Invoices Made Easy!
- http://www.k-billing.com
"D. Richard Hipp" <[EMAIL PROTECTED]> writes:
> A similar bug exists in 2.8. A fix has been checked
> into CVS. Version 2.8.16 will be released as soon as
> I can get it built and tested.
Great. I don't know if you forgot about the patch I sent a while ago, or
decided not to include it. Here
On Fri, 2005-02-11 at 21:04 -0500, [EMAIL PROTECTED]
wrote:
> "D. Richard Hipp" <[EMAIL PROTECTED]> writes:
>
> > While on the airplane, I was able to reproduce the problem
> > and confirm that it is possible to corrupt a database
> > as described above. I've just checked in a tentative fix.
> >
Clay Dowling <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
>>Do you know if this bug exist in 2.8.15 as well? If so, is the fix
>>back-portable?
>>
>>
> Darrell,
>
> I believe that the VACUUM statement didn't exist in 2.8.x, so there shouldn't
> be a problem.
Sure it does. I use it i
Clay and Derrell,
Clay Dowling wrote:
[EMAIL PROTECTED] wrote:
Do you know if this bug exist in 2.8.15 as well? If so, is the fix
back-portable?
Darrell,
I believe that the VACUUM statement didn't exist in 2.8.x, so there
shouldn't be a problem.
That's not true. It did exist in 2.8.15. I've
[EMAIL PROTECTED] wrote:
Do you know if this bug exist in 2.8.15 as well? If so, is the fix
back-portable?
Darrell,
I believe that the VACUUM statement didn't exist in 2.8.x, so there
shouldn't be a problem.
Clay
On Fri, 2005-02-11 at 06:11 -0500, D. Richard Hipp wrote:
> On Fri, 2005-02-11 at 10:29 +0200, Cariotoglou Mike wrote:
> > It has been my experience that, when two processes have the same db
> > open, and one of them does a VACUUM, and the other tries to update,
> > The database gets corrupted. Not
"D. Richard Hipp" <[EMAIL PROTECTED]> writes:
> While on the airplane, I was able to reproduce the problem
> and confirm that it is possible to corrupt a database
> as described above. I've just checked in a tentative fix.
> After some more testing, I will do a new release, probably
> 3.1.2 (stab
cc:
Subject: RE: [sqlite]
VACUUM question
02/11/2005 09
> <[EMAIL PROTECTED]cc:
>
>
OTECTED]cc:
ar.gr> Subject: RE: [sq
To:
<[EMAIL PROTECTED]cc:
ar.gr> Subject: RE: [sql
On Fri, 2005-02-11 at 10:29 +0200, Cariotoglou Mike wrote:
> It has been my experience that, when two processes have the same db
> open, and one of them does a VACUUM, and the other tries to update,
> The database gets corrupted. Not easy to simulate, but has happened at
> least twice, in fact it h
, DRH ?
> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 10, 2005 12:14 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] VACUUM question
>
> On Wed, 2005-02-09 at 14:56 -0500, Luc Vandal wrote:
> > if my ap
Just curious. What is it that is motivating you to vacuum so frequently?
Regards.
rayB
*** Confidentiality and Privilege Notice ***
This e-mail is intended only to be read or used by the addressee. It is
confidential and may contain legally privileged informat
At 14:56 09/02/2005 -0500, Luc wrote:
My application does a VACUUM everytime it is launched. This slows down the
application a little (it's a plugin for Outlook so it freezes Outlook for a
second or two at most, but users could find that annoying). So I was
wondering if my app has a sqlite3* pointe
On Wed, 2005-02-09 at 14:56 -0500, Luc Vandal wrote:
> if my app has a sqlite3* pointer to the database and another app does
> a VACUUM on the same database, will the pointer still be valid?
Yes.
>
> Also, what if, while doing a VACUUM, a query executes on the database?
> Will it just fail?
Y
Hi,
My application does a VACUUM everytime it is launched. This slows down the
application a little (it's a plugin for Outlook so it freezes Outlook for a
second or two at most, but users could find that annoying). So I was
wondering if my app has a sqlite3* pointer to the database and another
Hello All,
Recently, I have installed sqlite3 and trying to get a very simple
database application working with it. My application is in C++. I am
trying to use sqllite3_exec and sqlite3_get_table etc to insert records
into my database. I have already created a table and database pointer is
alre
Thank you very much to all who replied to me. I misunderstood the vacuum
function.
I had problems with my output routine because of the empty spaces. I thought
to solve the problem that way.
I have just solved the problem by using another output routine.
Regards Daniel
> > I have deleted some obj
> I have deleted some objects in my database. Now I have objects at id
> (INTEGER PRIMARY KEY) =1,3,4,5,7,8,9,16,17,20 .
> id=2,6,10,.. are empty. I want to defrag the database so that I have
objects
> continuously at id=1,2,3,4,5,6,7,...
The first question I'd have to ask is why you want to d
On Dec 28, 2004, at 11:44 AM, D.W. wrote:
Is there a function that does what I have described?
[described... 'compact' the primary keys of a database so that there
are no unused gaps after a row or rows have been deleted]
No. And, generally, you really don't want to do that.
The primary keys are
101 - 200 of 209 matches
Mail list logo
