Re: [sqlite] SQLite performance for 10 Million Records

Joe Wilson wrote: --- Martin Jenkins <[EMAIL PROTECTED]> wrote: For :memory: databases, long periods were observed where the VM size crept up but I/O write bytes did not, followed by periods where I/O bytes increased. If you use "PRAGMA temp_store=MEMORY" with your :memory: database you will

[sqlite] sqlite and in memory databases

i am looking for a embeddable sql database that i can use to manipulate memory stored in battery back sram. would sqllite be cable of doing this? thanks j osburn

Re: [sqlite] Hardcopy docs?

> Do you know exactly which version of SQLite the book discusses? > Version 3.3.x. The examples all use 3.3.4. For what it is worth, my review of the book is at: http://www.rogerbinns.com/sqlitereview.html Roger

Re: [sqlite] Memory vs File: speed improvement factor ?

It also depends on the synchronous pragma. If you leave synchronous on with a disk DB, you will see a huge improvement with an "in-memory". With synchronous off, there is not that big an improvement until you start inserting large amounts of data. You will then start seeing a slight improvement. T

[sqlite] SQLite on Zeta: SQL error: kernel lacks large file support

Hi, I've successfully built SQLite 3.3.6 on Zeta 1.2 but it fails with the following error: sqlite> create table files (name text, contents blob); SQL error: kernel lacks large file support Would anyone here have a clue as to what function might return such an error? I'm not well enough ve

Re: [sqlite] Hardcopy docs?

On 26 Jun 2006 at 14:14, [EMAIL PROTECTED] wrote: > "Bernie Cosell" <[EMAIL PROTECTED]> wrote: > > I'll confess that I am an old-fashioned "hardcopy" kind of guy... are the > > sqlite3 docs available in any sort of reasonably-printable format? > > > > http://www.apress.com/book/bookDisplay.html

Re: [sqlite] Memory vs File: speed improvement factor ?

--- "Meier, Roger" <[EMAIL PROTECTED]> wrote: > Hi, > > What factor of speed improvement could I expect with a memory database? > > The database is located on compact flash(vfat) and has a size of 1 MB. > > Thank you very much > > Roger Meier It depends what you mean by 'memory database' and t

Re: [sqlite] SQLite performance for 10 Million Records

> I think some other factor is at play here. > SQLite 2.x's memory databases are still twice as fast at batch inserts > than either 3.x's disk-based databases or 2.x's disk-based databases > when the DB size is less than physical machine memory. I did some experimentation with an SQLite 2.8.17 :m

Re: [sqlite] SQLite performance for 10 Million Records

--- Martin Jenkins <[EMAIL PROTECTED]> wrote: > For :memory: databases, long periods > were observed where the VM size crept up but I/O write bytes did not, > followed by periods where I/O bytes increased. If you use "PRAGMA temp_store=MEMORY" with your :memory: database you will have no I/O wh

Re: [sqlite] SQLite performance for 10 Million Records

Hi, I am really really thankful to all the members of this group. The Discussion here was really very helpful for me and also for the others. I was not as much experienced as the other members who took part in this dicussion, but i worked hard ad spent a lot of time to find out why i am getti

Re: [sqlite] SQLite Path Problem On Fedora Core 5

Robert L Cochran wrote: How do I fix my sqlite version mess so that I can have multiple installed versions: the one used by yum (and possibly other modules) and the latest and greatest release, which I want to link into PHP for my own purposes. (Yes I compile PHP on my own.) With an up to

Re: [sqlite] SQLite Path Problem On Fedora Core 5

DJ Anubis wrote: Robert L Cochran a écrit : However, on Fedora Core 5, my path is set so that objects on /usr/local/bin are found before those on /usr/bin. I'm not sure how this is happening; perhaps /etc/profile? The result seems to be that even if sqlite 3.3.3 was installed by yum, executi

Re: [sqlite] v3.2.1 and current differences!

At 4:01 PM -0400 6/26/06, [EMAIL PROTECTED] wrote: Peter Bierman <[EMAIL PROTECTED]> wrote: At 2:20 PM -0400 6/26/06, [EMAIL PROTECTED] wrote: >SQLite 3.3.0 can read and write all prior versions of SQLite >databases. But SQLite 3.2.8 cannot read or write a database >created by SQLite 3.3.0,

Re: [sqlite] Database locked. Any idea ?

Just wanted to give an update in case someone follows this thread in the message archive later on. I found the problem, it was the silicon that was not doing certain memory accesses properly. As they say, always blame the hardware. Thanks, Mario Hebert [EMAIL PROTECTED] 06/20/2006 03:07

Re: [sqlite] v3.2.1 and current differences!

Thanks, but do not base your decision on my. I'm using sqlite to little to complain, i simply was not aware of the change. I write software to make use of sqlite for other people (a designer). I only need to mention this issue. - Original Message - From: <[EMAIL PROTECTED]> To: Se

Re: [sqlite] v3.2.1 and current differences!

Peter Bierman <[EMAIL PROTECTED]> wrote: > At 2:20 PM -0400 6/26/06, [EMAIL PROTECTED] wrote: > >SQLite 3.3.0 can read and write all prior versions of SQLite > >databases. But SQLite 3.2.8 cannot read or write a database > >created by SQLite 3.3.0, unless you use > > > > PRAGMA legacy_file_forma

Re: [sqlite] v3.2.1 and current differences!

"C.Peachment" <[EMAIL PROTECTED]> wrote: > You can create the database with the older Sqlite version, but any use > with the new version must be preceded by the pragma, otherwise the > new version changes the data format, making it unreadable by the > old version thereafter. > The file format is

Re: [sqlite] v3.2.1 and current differences!

At 2:20 PM -0400 6/26/06, [EMAIL PROTECTED] wrote: SQLite 3.3.0 can read and write all prior versions of SQLite databases. But SQLite 3.2.8 cannot read or write a database created by SQLite 3.3.0, unless you use PRAGMA legacy_file_format=TRUE; prior to creating the database, or unless you co

Re: [sqlite] v3.2.1 and current differences!

"Edwin Knoppert" <[EMAIL PROTECTED]> wrote: > A bit odd the system does not handle backwards compatibility in minor > releases. > It *does* handle backwards compatibility. It is forwards compatibility that causes problems. Newer versions of SQLite can read databases generated by all older vers

Re: [sqlite] v3.2.1 and current differences!

You can create the database with the older Sqlite version, but any use with the new version must be preceded by the pragma, otherwise the new version changes the data format, making it unreadable by the old version thereafter. It got me confused when I started too. On Mon, 26 Jun 2006 21:28:59 +

Re: [sqlite] v3.2.1 and current differences!

After opening the database file with a later library version and before doing anything else, issue the command: Sorry, maybe i misunderstood. The db is created with the latest release, v3.2.1 did not manage to read it. Maybe the pragma helps anyway.. - Original Message - From: "C.Peach

Re: [sqlite] Hardcopy docs?

Excellent. I'll start saving my pennies!! Alex [EMAIL PROTECTED] wrote: Alex Roston <[EMAIL PROTECTED]> wrote: Do you know exactly which version of SQLite the book discusses? Version 3.3.x. -- D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] v3.2.1 and current differences!

OK, thanks! Must been a change in the fileformat then.. A bit odd the system does not handle backwards compatibility in minor releases. :) PS, still can't find my own post, while a reply is given.. odd - Original Message - From: "C.Peachment" <[EMAIL PROTECTED]> To: Sent: Monday,

Re: [sqlite] Hardcopy docs?

Alex Roston <[EMAIL PROTECTED]> wrote: > Do you know exactly which version of SQLite the book discusses? > Version 3.3.x. -- D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] Hardcopy docs?

Do you know exactly which version of SQLite the book discusses? Thanks Alex [EMAIL PROTECTED] wrote: "Bernie Cosell" <[EMAIL PROTECTED]> wrote: I'll confess that I am an old-fashioned "hardcopy" kind of guy... are the sqlite3 docs available in any sort of reasonably-printable format?

Re: [sqlite] v3.2.1 and current differences!

"Edwin Knoppert" <[EMAIL PROTECTED]> wrote: > Just wanted to warn you i can not read a newly created table created with > the current release and opening it in v3.2.1 (afaik) > > Sorry, i removed the older dll, i overwrote it with the latest and read the > table instantly. > Before i had 0 table

Re: [sqlite] v3.2.1 and current differences!

On Mon, 26 Jun 2006 20:03:35 +0200, Edwin Knoppert wrote: >Just wanted to warn you i can not read a newly created table created with >the current release and opening it in v3.2.1 (afaik) >Sorry, i removed the older dll, i overwrote it with the latest and read the >table instantly. >Before i had

Re: [sqlite] Hardcopy docs?

"Bernie Cosell" <[EMAIL PROTECTED]> wrote: > I'll confess that I am an old-fashioned "hardcopy" kind of guy... are the > sqlite3 docs available in any sort of reasonably-printable format? > http://www.apress.com/book/bookDisplay.html?bID=10130 -- D. Richard Hipp <[EMAIL PROTECTED]>

[sqlite] v3.2.1 and current differences!

Just wanted to warn you i can not read a newly created table created with the current release and opening it in v3.2.1 (afaik) Sorry, i removed the older dll, i overwrote it with the latest and read the table instantly. Before i had 0 tables shown. A simple query was used: CREATE TABLE [TABL

[sqlite] Hardcopy docs?

I'll confess that I am an old-fashioned "hardcopy" kind of guy... are the sqlite3 docs available in any sort of reasonably-printable format? /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <

Re: [sqlite] how make a case insensitive index

Thank you for the advice and the url :) -- View this message in context: http://www.nabble.com/how-make-a-case-insensitive-index-t1849023.html#a5049996 Sent from the SQLite forum at Nabble.com.

Re: [sqlite] Re: problem with creating a table

Fred Williams wrote: If brackets are a visual distraction, more common " Quote Marks may be used as well. Not only are double quote characters more common, they are the standard method for quoting names in SQL. The square brackets are a non-standard extension introduced by Microsoft in Ac

Re: [sqlite] SQLite performance for 10 Million Records

Dennis Cote wrote: Joe Wilson wrote: I think some other factor is at play here. Yes there is another factor at work here. [...] I suspect there are optimizations that could be made to the memory I/O routines to speed them up, they should at least be able to run slightly faster than file ba

Re: [sqlite] how make a case insensitive index

* Wilfried Mestdagh <[EMAIL PROTECTED]> [2006-06-26 15:45]: > How to make a case insensitieve index ? Add `COLLATE NOCASE` to the column definition. See http://www.sqlite.org/datatype3.html Regards, -- Aristotle Pagaltzis //

Re: [sqlite] how make a case insensitive index

Hi, Made an extra field with a lowercase portion of the field I wants to sort on. I think it is the most fast. Of course when someone can give better advice it is very welcome :) rgds, Wilfried -- View this message in context: http://www.nabble.com/how-make-a-case-insensitive-index-t1849023.htm

Re: [sqlite] SQLite performance for 10 Million Records

Joe Wilson wrote: I think some other factor is at play here. SQLite 2.x's memory databases are still twice as fast at batch inserts than either 3.x's disk-based databases or 2.x's disk-based databases when the DB size is less than physical machine memory. Joe, Yes there is another factor

[sqlite] how make a case insensitive index

Hi, How to make a case insensitieve index ? I tryed with [lower(fieldname)] and other combinations but this give me a syntax error. The select will work with 'order by lower(fieldname)' but it should use the right index. -- View this message in context: http://www.nabble.com/how-make-a-case-ins

Re: [sqlite] Sqlite crashes when i imort huge list

On 6/26/06, C.Peachment <[EMAIL PROTECTED]> wrote: >>The use of sequential numbers as the trailing part of the 'word' >>results in a continual rebalancing of the b-tree with each insertion. >Is that right considering it looks like you have not created an index on >the word column before inserti

Re: [sqlite] Memory vs File: speed improvement factor ?

--- John Stanton <[EMAIL PROTECTED]> wrote: > Meier, Roger wrote: > > Hi, > > > > What factor of speed improvement could I expect > with a memory database? > > > Little to none > This is my experience as well, under a variety of conditions that I have tested. It is interesting; at times, it m

Re: [sqlite] Where is the sqlite3.h file?

The .h file is in the preprocessed source. The def file lists the exports from the dll, which is useful when some new experimental functions get defined in the .h file, but are not yet exported form the Dll. On 25/06/06, onemind <[EMAIL PROTECTED]> wrote: Hi, I am trying to use the .dll with c

Re: [sqlite] Problem with lempar.c revision 1.17

On 6/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: "Garrett Rooney" <[EMAIL PROTECTED]> wrote: > > > > Your grammer does not generate an empty string. That means > > if you call the parser with an EOF token first, without any > > prior tokens, you are going to get a syntax error. The > >

Re: [sqlite] Problem with lempar.c revision 1.17

"Garrett Rooney" <[EMAIL PROTECTED]> wrote: > > > > Your grammer does not generate an empty string. That means > > if you call the parser with an EOF token first, without any > > prior tokens, you are going to get a syntax error. The > > "yymajor==0" test was removed in order to get this to > > w

Re: [sqlite] Memory vs File: speed improvement factor ?

Meier, Roger wrote: Hi, What factor of speed improvement could I expect with a memory database? The database is located on compact flash(vfat) and has a size of 1 MB. Thank you very much Roger Meier Little to none

RE: [sqlite] Sqlite crashes when i imort huge list

On Mon, 26 Jun 2006 11:20:59 +0100, Brandon, Nicholas (UK) wrote: >>The use of sequential numbers as the trailing part of the 'word' >>results in a continual rebalancing of the b-tree with each insertion. >Is that right considering it looks like you have not created an index on >the word column

RE: [sqlite] Sqlite crashes when i imort huge list

>The use of sequential numbers as the trailing part of the 'word' >results in a continual rebalancing of the b-tree with each insertion. Is that right considering it looks like you have not created an index on the word column before inserting the data? Nick ***