1 Aug 2006 06:18
1 Aug 2006 07:39
IO Access Time
Hi All, I am planning to migrate to SQLite for my embedded system application. Currently we have a flat text file which we read and write using normal C++ routines. Whole of the configuration is written everytime some change happens. We do it using ofstream. For reading any object, we keep all the objects in memory and return from there (to prevent file read every time). This takes up a lot of memory but makes it faster. I am a bit concerned about following issues while upgrading to SQLite : 1. How does SQLite behave as compared to our current approach regarding I/O access time ? 2. How much disk space does SQLite take as compared to flat text file ? If somebody has some benchmarking data for these issues, it will be really helpful if he can enlighten me on this. Thanks in advance, Regards, Aseem. -- -- Nothing will work unless u do.
1 Aug 2006 07:37
Moving journal storage to another location...
Is there a way to move the journal to say use a temp directory? We're doing some stuff with dbs on SD-cards and it's dog slow. Writing to them is dog slow too. So is transacting to them. 3 writes on sloooow media. Is there a way to have the journal in the faster local flash memory, then when it's done/committed, have that written to the sd media? Thanks in advance, Bill. -- -- Bill King, Software Engineer Trolltech, Brisbane Technology Park 26 Brandl St, Eight Mile Plains, QLD, Australia, 4113 Tel + 61 7 3219 9906 (x137) Fax + 61 7 3219 9938 mobile: 0423 532 733
1 Aug 2006 10:42
Re: Re: insert default values - supporting it?
I refined the patch. it constructs a list of values with one NULL, but I don't see how to construct an idList with just the primary key. also added the grammar rule to recognize both: insert into <table> default values; insert into <table> () values (); anybody completing/correcting the work? sqlite> insert into test () values (); SQL error: table test has 3 columns but 1 values were supplied MF.
1 Aug 2006 10:58
1 Aug 2006 11:42
1 Aug 2006 11:48
1 Aug 2006 12:08
Re: Reading a damaged database file?
Hi, Is there a way to do this programmatically? I would like to recover from a damaged database upon program startup. Regards, Olaf ----- Original Message ----- From: "Christian Smith" <csmith@...> To: "SQLite Mailing List" <sqlite-users@...> Sent: Monday, July 31, 2006 4:53 PM Subject: Re: [sqlite] Reading a damaged database file? Olaf Beckman Lapr uttered: > Hi, > > Is it possible to read the undamaged parts of a damaged .db file? This > way I can copy the undamaged parts to another database. Or support to > repair the .db file in such a way that it becomes readable again and the > undamaged parts can be read. You can try doing a .dump from the SQLite shell. It will dump out as much data that can be read without errors. > > Olaf(Continue reading)
1 Aug 2006 12:35
Re: Reading a damaged database file?
=?utf-8?Q?Olaf_Beckman_Lapr=C3=A9?= <obeckman <at> wanadoo.nl> wrote: > Hi, > > Is there a way to do this programmatically? I would like to recover from a > damaged database upon program startup. > If your program crashes, or your computer loses power in the middle of a database change, and thus leaves the database in an inconsistent state, recovery is automatic. You do not need to do anything. The database automatically reverts to its prior state. If, however, you set "PRAGMA synchronous=OFF" or if you delete a hot journal file, or if you write random garbage into the middle of a database file, then there isn't much you can do to recover. How exactly is your database being damaged and why do you think you need some kind of automatic recovery mechanism over and above what is already implemented? -- D. Richard Hipp <drh <at> hwaci.com>
1 Aug 2006 12:37
Re: Moving journal storage to another location...
Bill KING <bill.king <at> trolltech.com> wrote: > Is there a way to move the journal to say use a temp directory? We're > doing some stuff with dbs on SD-cards and it's dog slow. Writing to them > is dog slow too. So is transacting to them. 3 writes on sloooow media. > Is there a way to have the journal in the faster local flash memory, > then when it's done/committed, have that written to the sd media? > The journal file must be in the same directory as the original database so that a hot journal (that results from a program crash or system power failure) can be located and used to rollback changes the next time some other program tries to open the database file. If the next user of the database cannot locate the hot journal, the journal will not be played back and the database will not be restored to a consistent state. -- D. Richard Hipp <drh <at> hwaci.com>
RSS Feed