Re: [sqlite] Precompiled binaries for Windows Not Version 3.5.5

"Zarko Popovski" <[EMAIL PROTECTED]> wrote: > I see also SQLite 5.5.4 version compiled, is there SQLite 3.5.5 precompiled > version for M$ Windows or if there is not drh. please compile it :) > I fixed that problem this morning. When did you last look? -- D. Richard Hipp <[EMAIL PROTECTED]> -

Re: [sqlite] Precompiled binaries for Windows Not Version 3.5.5

I see also SQLite 5.5.4 version compiled, is there SQLite 3.5.5 precompiled version for M$ Windows or if there is not drh. please compile it :) On Feb 1, 2008 12:15 AM, Robert Wishlaw <[EMAIL PROTECTED]> wrote: > Under the Precompiled binaries for Windows section of the downloads > page, the sqli

[sqlite] SQLite 3.5.5 make test on OpenBSD 4.2 on HPPA

rerun, with chocolate directory removed prior to test run. ./testfixture ../test/quick.test bind-4.4... Error: floating point value is Not a Number bind-4.5... Expected: [null real real] Got: [] btree-2.1.1...CURSOR 4041F588 rooted at1(rw) currently at 1.0 eof PAGE 1: flags=0x09 frag=

Re: [sqlite] db4o 500x faster than sqlite?

gerpux wrote: > > I've heard that the guys at db4o said that, under certain > circunstances, db4o is 500x faster than sqlite: > Is this because of the jdbc driver? > What would be a more realistic measure? (db4o is an object database, > not a relational one) > They are using the poleposition ben

Re: [sqlite] memory issue with large amount of inserts

I read pieces of information from other threads but I got more confused... I think I d better ask this question first: how exactly does sqlite manage memory usage, when does it attemp to release memory? Does page size/ number of pages affect insert operations? Does transactional-insert lock up mem

RE: [sqlite] Using LIKE to check the first digits?

Regarding: >>Indices won't help with LIKE unless the column as a NOCASE collation. Use GLOB instead: >> ... WHERE number GLOB '1234*'; >>Note that "*" is the wildcard character with GLOB, not "%" >>as in LIKE. The above will use an index on the number column if it is available.

[sqlite] 3.5.5. Bus error on HPUX

I think this is probably a very simiilar issue as found on the solaris. The error occurred during asyn3.test. Here is the gdb output analyze-99.1... Ok async3-1.0... Ok async3-1.1...make: *** [test] Bus error (core dumped) hermes:herm10:/home/ixion/LIB/sqliteSrc/tst>> ls core core hermes:herm10:

Re: [sqlite] SQLite 3.5.5 on OpenBSD running on HPPA (HP9000) make test

On Fri, 1 Feb 2008, [EMAIL PROTECTED] wrote: We do not understand the async3 problem and cannot reproduce it. All the other issues have been fixed in CVS HEAD. Actually, upon inspection, that may be an artifact of an earlier attempt to run the tests as root, the "chocolate" directory was, in

RE: [sqlite] Using LIKE to check the first digits?

If you need LIKE 'abc%' and for it to not be case insensitive, then LIKE is preferred. Also, LIKE is standard SQL so if you're writing SQL that has to run across different vendors, you'd use LIKE. Sam --- We're Hiring! Seeking a passionate developer to

Re: [sqlite] SQLite 3.5.5 on OpenBSD running on HPPA (HP9000) make test

Rob Sciuk <[EMAIL PROTECTED]> wrote: > Dear DRH, > > I post the previous (FreeBSD/Ubuntu) and this *ONLY* to exercise the new > 3.5.5 bits given the wholsale changes. I hope you find them useful, but > AFAICT, 3.5.5 looks pretty good from a perf/stability standpoint. > > In the obscure machine/O

[sqlite] SQLite 3.5.5 on OpenBSD running on HPPA (HP9000) make test

Dear DRH, I post the previous (FreeBSD/Ubuntu) and this *ONLY* to exercise the new 3.5.5 bits given the wholsale changes. I hope you find them useful, but AFAICT, 3.5.5 looks pretty good from a perf/stability standpoint. In the obscure machine/OS category, I lit this up on an HP9000 K200 runn

Re: [sqlite] Solaris bus error

Dan I thought the test was from async3.test... But I'm probably wrong. I got the info from ddd and asked it to tell me the contents of ppLock which was 0. Here is the output directly from gdb as you requested. print *ppLock $1 = (struct lockInfo *) 0x0 gdb) info threads 4 process 262671

Re: [sqlite] memory issue with large amount of inserts

Thanks. I did force GC in the development IDE but still that doest solve the problem. Is it possible to set a heap size limit to sqlite - i noticed this is possible in C, but is anyone aware of a JAVA equivalent way? Thanks Jonas Sandman wrote: > > I guess it's not as simple as that you're a

Re: [sqlite] memory issue with large amount of inserts

just to add that I am using transaction, and the batch size is 2000 zqzuk wrote: > > Hi, I am using SQLite 3.5.4, my application has encountered a memory > management issue which I think is caused by sqlite. I have searched the > forum and found this thread describing most similar situation a

Re: [sqlite] memory issue with large amount of inserts

I guess it's not as simple as that you're application is hogging the Java VM so much that the garbage collector is never running? You can always force it to run explicitly if so... /Jonas On Fri, Feb 1, 2008 at 1:46 PM, zqzuk <[EMAIL PROTECTED]> wrote: > > Hi, I am using SQLite 3.5.4, my applica

[sqlite] memory issue with large amount of inserts

Hi, I am using SQLite 3.5.4, my application has encountered a memory management issue which I think is caused by sqlite. I have searched the forum and found this thread describing most similar situation as mine http://www.nabble.com/Memory-Usage-to13798003.html#a13850915 My application is acces