[sqlite] SqLite db ODBC
I am trying to locate an ODBC driver that I can use in the Windows Data Link. Is this doable? Does one exist? Thanks, Barry ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite C++
Hi Is there any future plan to develop sqlite in C++. Rajesh Nair ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite C++
On 5/29/08, Rajesh Nair <[EMAIL PROTECTED]> wrote: > Hi > > Is there any future plan to develop sqlite in C++. Didn't you (or someone else) just ask that just a couple of days ago? I would say the chances of SQLite++ are less than zero (thank heavens), but for more details, search the list for an answer. > > Rajesh Nair ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite C++
Rajesh Nair wrote: > Hi > > Is there any future plan to develop sqlite in C++. > Why would anybody want to do that? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite C++
>> Is there any future plan to develop sqlite in C++. >> > > Why would anybody want to do that? Maybe he is looking for a C++ wrapper for Sqlite. http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite C++
dcharno wrote: >>> Is there any future plan to develop sqlite in C++. >>> >> Why would anybody want to do that? > > Maybe he is looking for a C++ wrapper for Sqlite. Than look no further. SOCI is the definite sqlite c++ wrapper. http://soci.sourceforge.net/ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite C++
Darko Miletic wrote: > Rajesh Nair wrote: >> Hi >> >> Is there any future plan to develop sqlite in C++. >> > > Why would anybody want to do that? Sabotage? > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Sqlite 3.5.9 journal_mode vs ext3 journaling
I was under the impression that setting PRAGMA synchronous=NORMAL also removed the fsync() at step 6. I'm pretty sure when we run with synchronous=NORMAL we see only one fsync() call per COMMIT operation, not 2 (and definitely not 3 as we see with synchronous=FULL). --Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of D. Richard Hipp Sent: Thursday, May 22, 2008 6:06 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Sqlite 3.5.9 journal_mode vs ext3 journaling On May 22, 2008, at 6:50 PM, Bob Ebert wrote: > I wonder if anyone is in a position to compare and contrast the > journal_mode and synchronous settings with the various ext3 journal > modes? > > Up until now we've been using ext3 with data=ordered, and sqlite3 with > synchronous=normal, journal_mode=delete. We're on an embedded system > with a very high frequency of random power cycling. In this mode, > we've seen an unusually large number of corrupted databases. > > My best theory right now is that we lose power after the ext3 metadata > has written the delete of the -journal file, but before all of the > page overwrites for the db file are fully flushed, since these are > done by two different processes in normal linux. SQLite calls fsync() before it calls unlink() on the journal file. So if fsync() is working as documented, all database data should be safely on oxide prior to the unlink(). We have seen instances before where fsync() returned long before the data was on oxide, so I would not be surprised by this. You can often see this yourself by mounting a flash memory stick, writing a file on the stick, calling fsync() then watching the LED on the end of the stick continue to flash long after the fsync() has returned. Please recognize that there really is nothing that SQLite can do to correct this problem. SQLite depends on the operating system and/or disk controller living up to its end of the contract. If the disk says all data is on oxide, SQLite has no choice but to believe it because SQLite has no way to independently verify the matter. And if the disk controller and/or operating system is lying, and a power failure follows, the database can be corrupted. There isn't much you can do when your hardware starts lying to you. > I believe if we lose power at > this point, then after a restart ext3 will replay the journal delete, > but will leave the main DB in a semi-written state, and thus corrupt > the DB. > > I'm wondering what impact switching to journal_mode=persist will have > on this scenario. I believe this will change how the last step of the > atomic commit (clearing the journal) is written to disk, and thus > changes how ext3 will recover the file after a power loss. Currently > our IO scheduler doesn't guarantee ordered writes, so in theory the > journal header clearing could still make it to disk before all the > main db pages. We're in a position to adjust the IO scheduler if > necessary to prevent this. Once again, SQLite calls fsync() on the database prior to calling write() to clear the journal header. So *if* fsync is doing its job, you should have no problems. *If*. Note the the whole point of these fsync() calls in SQLite is to act as an I/O barrier operation - to guarantee that all I/O operations that are issued prior to the fsync() complete prior to any I/O operations issued afterwards. We must have an I/O barrier in order to preserve database integrity across a power failure. If your fsync() is not work quite right, then all bets are off. I don't know of anything SQLite can do to make the situation better. > > > Are there any other potential holes or races between ext3 journal data > and sqlite file contents that I should worry about? Is > synchronous=full the only way to guarantee atomic commits under these > conditions? > A synchronous=FULL commit goes like this: 1. Write all pages that will change into the journal 2. fsync() the journal 3. Overwrite the journal header to indicate that it is valid 4. fsync() the journal 5. Write changes into the database file. 6. fsync() the database files 7. Delete or truncate or overwrite the journal header (depending on journaling mode) The difference between FULL and NORMAL is that NORMAL omits the fsync() on step 2. That is the only difference. The step-2 fsync is important on some filesystems, but on ext3 it is probably unnecessary. So I don't think that going to synchronous=FULL is going to help you. D. Richard Hipp [EMAIL PROTECTED] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlit
Re: [sqlite] Sqlite 3.5.9 journal_mode vs ext3 journaling
On May 29, 2008, at 4:13 PM, Bob Ebert wrote: > I was under the impression that setting PRAGMA synchronous=NORMAL also > removed the fsync() at step 6. I'm pretty sure when we run with > synchronous=NORMAL we see only one fsync() call per COMMIT operation, > not 2 (and definitely not 3 as we see with synchronous=FULL). > Each COMMIT with synchronous=NORMAL should do one fsync() of the journal file and one fsync() of the database file. There might also be an fsync() of the directory that contains the journal and database files when the journal file is first created. (Not sure about that last one -- been a while since I looked at that code.) D. Richard Hipp [EMAIL PROTECTED] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Database Corruption
Some more details: The scenario here is: DB->Exec(Begin); //Transaction begin DB->Step(); // Execute my query that is trying to insert a record in the db DB->Exec(End); //End the transaction When the last step is executed i.e. the end step, I am seeing that Sqlite now tries to write the record to the filesystem using sqlite3OsWrite(). There are 5 sqlite3OsWrite() calls to this function made in this scenario. To emulate a scenario where the filesystem would be interrupted I allow only 2 writes and then shutdown the application. The next time I bring up the application and open the database, then the database is sometimes (a) not able to find even any previous records that were there in the database (b) database gets corrupted in the sense that it returns incorrect values when queried. I used the SQLite-Browser (http://sqlitebrowser.sourceforge.net) on Windows to open my database and it was able to read all the previous records fine. So it clearly is that sqlite implementation that is being used by my application is not able to recover from a partial I/O commit. The sqlite version that I have is 3.0.8. manas.abi wrote: > > I get this problem only after I stop a transaction in between which makes > me think that there is a problem with SQLite code. > > Also, I forgot to mention that I am using SQLite version 3.0.8. Do you > know about any such bug in this version which was removed in the later > versions? > > Thanks & Regards > Manas > -- View this message in context: http://www.nabble.com/Database-Corruption-tp17523984p17545283.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Database Corruption
On May 29, 2008, at 4:38 PM, manas.abi wrote: > > Some more details: > > The scenario here is: > DB->Exec(Begin); //Transaction begin > DB->Step(); // Execute my query that is trying to insert a record in > the db > DB->Exec(End); //End the transaction > > When the last step is executed i.e. the end step, I am seeing that > Sqlite > now tries to write the record to the filesystem using > sqlite3OsWrite(). > There are 5 sqlite3OsWrite() calls to this function made in this > scenario. > To emulate a scenario where the filesystem would be interrupted I > allow only > 2 writes and then shutdown the application. The next time I bring up > the > application and open the database, then the database is sometimes > (a) not > able to find even any previous records that were there in the > database (b) > database gets corrupted in the sense that it returns incorrect > values when > queried. > > I used the SQLite-Browser (http://sqlitebrowser.sourceforge.net) on > Windows > to open my database and it was able to read all the previous records > fine. > So it clearly is that sqlite implementation that is being used by my > application is not able to recover from a partial I/O commit. > > The sqlite version that I have is 3.0.8. After you shutdown your application, there should be two files left over: database.db and database.db-journal. Make copies of those files for a cases where the database does not recover upon restart, and send me those files, and then (and only then) I will believe you. We do extensive and detailed tests of SQLite in which the application is terminated abruptly in the middle of a transaction, exactly as you describe above, and then verify that the transaction automatically rolls back to its original state. We have done so since version 3.0.0. D. Richard Hipp [EMAIL PROTECTED] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite C++
Rajesh Nair wrote: > Hi > > Is there any future plan to develop sqlite in C++. > Given that C++ has source and binary compatibility with C, I don't think there would be any point. I develop in C++ using SQLite quite happily, and see no reason to stop now. Clay ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] get the actual database size.
Hi All, I have the database which has a lot of insertion and deletion. Is there anyway that I can get the actual database size without running VACUUM. Thanks, JP ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] get the actual database size.
On 5/29/08, Joanne Pham <[EMAIL PROTECTED]> wrote: > Hi All, > I have the database which has a lot of insertion and deletion. > Is there anyway that I can get the actual database size without running > VACUUM. Your question implies that VACUUM lets you "get the database size." No, it doesn't. VACUUM recovers the space left behind by deleting data from the db. To find out the size of the database, just read the size of the file in the operating system. Or, maybe you are asking something completely different that I don't get. > Thanks, > JP > > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] get the actual database size.
Joanne Pham wrote: Hi All, I have the database which has a lot of insertion and deletion. Is there anyway that I can get the actual database size without running VACUUM. Thanks, JP Hi, Joanne. I assume that by "actual database size" you mean "the size of the database file minus the size of the 'dead' space". If that assumption holds, then no, there is no way to do that using the public API - you would have to look at the actual VACUUM implementation and replicate the size calculations done there. So the answer would be no, you must run a VACUUM first. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] get the actual database size.
P Kishor wrote: > On 5/29/08, Joanne Pham <[EMAIL PROTECTED]> wrote: >> Hi All, >> I have the database which has a lot of insertion and deletion. >> Is there anyway that I can get the actual database size without running >> VACUUM. > > Your question implies that VACUUM lets you "get the database size." > No, it doesn't. VACUUM recovers the space left behind by deleting data > from the db. > > To find out the size of the database, just read the size of the file > in the operating system. > > Or, maybe you are asking something completely different that I don't get. I think what Joanne's asking is if it were possible to query what size the database would become if it were vacuumed without actually vacuuming it. Maybe as part of a cost analysis for whether to vacuum, or stats for the user as to how much of the database file is unused space. -- Darren Duncan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
