Re: [sqlite] SQLJet - pure Java implementation of SQLite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Williams wrote: > I say there is no known translation that > would allow the three SQLite, "Small, Fast, Reliable" adjectives to > translate into any regurgitated language output, with the exception of > compiling SQLite source with a C++

Re: [sqlite] SQLJet - pure Java implementation of SQLite

Having had the unfortunate opportunity to use a couple of language translators as well as spending about six fruitless months developing one which in the end was no better, I say there is no known translation that would allow the three SQLite, "Small, Fast, Reliable" adjectives to translate into

Re: [sqlite] UPDATE 11 times slower than SELECT?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nikolaus Rath wrote: > Is it normal that UPDATE still takes more than 11 times as much time as > SELECT, or should I be able to get better performance? The UPDATE time also includes the time waiting to acquire file locks. If you have concurrent

Re: [sqlite] UPDATE 11 times slower than SELECT?

"Igor Tandetnik" writes: > Nikolaus Rath wrote: >> When running apswtrace on my Python program, I got the following >> output: >> >> LONGEST RUNNING - AGGREGATE >> >> 16638 11.041 UPDATE inodes SET size=MAX(size,?), ctime=?, mtime=? >> WHERE id=? 16638 0.938 SELECT s3key

Re: [sqlite] UPDATE 11 times slower than SELECT?

Nikolaus Rath wrote: > When running apswtrace on my Python program, I got the following > output: > > LONGEST RUNNING - AGGREGATE > > 16638 11.041 UPDATE inodes SET size=MAX(size,?), ctime=?, mtime=? > WHERE id=? 16638 0.938 SELECT s3key FROM inode_s3key WHERE inode=? > AND offset=? > > i.e.

[sqlite] UPDATE 11 times slower than SELECT?

Hi, When running apswtrace on my Python program, I got the following output: LONGEST RUNNING - AGGREGATE 16638 11.041 UPDATE inodes SET size=MAX(size,?), ctime=?, mtime=? WHERE id=? 16638 0.938 SELECT s3key FROM inode_s3key WHERE inode=? AND offset=? i.e. both statements were executed

Re: [sqlite] SQLJet - pure Java implementation of SQLite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Kitaev wrote: > Not to depend on native SQLite binaries or > opaque NestedVM code, As a matter of interest what problem exactly do you have with NestedVM? It's output is indeed opaque (not human comprehensible) but the same is true of Java

Re: [sqlite] Busy Handler in Shared Cache Mode?

Hi, There has been a bit more discussion about this on http://code.google.com/p/apsw/issues/detail?id=59. I guesss Roger would be quite interested in the test case you mentioned. I have now decided to simply deactivate shared cache again. It seems the benefits aren't worth it in my case. As a

[sqlite] SQLJet - pure Java implementation of SQLite

Hello All, I'd like to invite those users who program in Java to take a look at our new project - SQLJet. SQLJet was started as part of another projects that has to work with SQLite database (SVNKit). Not to depend on native SQLite binaries or opaque NestedVM code, we've implemented part of

[sqlite] Help building SQLite project, please

This isn't directly related to SQLite, but rather to how I am converting the source code into a DLL. I hope someone here can help me understand what's happening. It appears that my previous problem was caused by some problem within the ancient, unbelievably slow and ugly library we have been

Re: [sqlite] resource temporarily unavailable after sqlite3_open()

D. Richard Hipp , On 8/11/2009 16:39: > program is using LinuxThreads or NPTL for its threading. (SQLite has > to know which is used because there are serious bugs in LinuxThreads > that SQLite has to work around.) So pthreads gets used once, by > SQLite, even if you don't do any threading in

Re: [sqlite] resource temporarily unavailable after sqlite3_open()

On Aug 11, 2009, at 4:28 PM, Mark Richards wrote: > D. Richard Hipp , On 8/11/2009 16:02: >> >> Perhaps pthreads is going goofy. Please recompile with - >> DSQLITE_THREADSAFE=0 and see if that helps. >> > BINGO. > > env CC="gcc-cris -mlinux -isystem $EROOT/include"CPP="gcc-cris > -mlinux

Re: [sqlite] resource temporarily unavailable after sqlite3_open()

D. Richard Hipp , On 8/11/2009 16:02: > > Perhaps pthreads is going goofy. Please recompile with - > DSQLITE_THREADSAFE=0 and see if that helps. > BINGO. env CC="gcc-cris -mlinux -isystem $EROOT/include"CPP="gcc-cris -mlinux -E -isystem $EROOT/include" CXX="g++-cris -mlinux -xc++

Re: [sqlite] resource temporarily unavailable after sqlite3_open()

On Aug 11, 2009, at 2:53 PM, Mark Richards wrote: > > When sqlite3_open() is called as above, got returns -1 (forever). -1 > returning from a NONBLOCK read is accepted behaviour, but pretty > quickly > the read() should give some data. Instead it returns -1 each time. > (If > I allow fd[0]

Re: [sqlite] resource temporarily unavailable after sqlite3_open()

Yes, tried that. No change in result. Assuming sqlite does a |F_GETFD| then restores when done. I built in some testing to see if the file descriptor was being mangled, and cannot detect any difference. Test: flags = fcntl(fd[0], F_GETFL, 0); char *cFlagMsg;

Re: [sqlite] resource temporarily unavailable after sqlite3_open()

On Aug 11, 2009, at 2:53 PM, Mark Richards wrote: > Environment: > Linux axis 2.6.19 #9 PREEMPT Mon Apr 6 15:44:03 EDT 2009 cris > unknown > > Sqlite: > Sqlite: sqlite-3.6.14 > ./configure --host=cris-axis-linux-gnu > --prefix=/AEMDEV/83+/devboard-R2_10/target/cris-axis-linux-gnu >

Re: [sqlite] resource temporarily unavailable after sqlite3_open()

I also (just) tried 3.6.17. Same issue. /m Mark Richards , On 8/11/2009 14:53: > Environment: > Linux axis 2.6.19 #9 PREEMPT Mon Apr 6 15:44:03 EDT 2009 cris unknown > > Sqlite: > Sqlite: sqlite-3.6.14 > ./configure --host=cris-axis-linux-gnu >

[sqlite] resource temporarily unavailable after sqlite3_open()

Environment: Linux axis 2.6.19 #9 PREEMPT Mon Apr 6 15:44:03 EDT 2009 cris unknown Sqlite: Sqlite: sqlite-3.6.14 ./configure --host=cris-axis-linux-gnu --prefix=/AEMDEV/83+/devboard-R2_10/target/cris-axis-linux-gnu --enable-static=yes --enable-shared=yes

Re: [sqlite] Cannot insert records into a table after dropping and recreating it

On 11 Aug 2009, at 4:50pm, Radcon Entec wrote: > At startup, the application creates three tables. If the file > previously existed, the create table queries fail. My code checks > the error message, and if it indicates that the table previously > existed, it ignores the error. Use the

Re: [sqlite] Cannot insert records into a table after dropping and recreating it

--- On Tue, 8/11/09, Radcon Entec wrote: > From: Radcon Entec > Subject: [sqlite] Cannot insert records into a table after dropping and > recreating it > To: sqlite-users@sqlite.org > Date: Tuesday, August 11, 2009, 10:50 AM > Greetings! > > I

[sqlite] Cannot insert records into a table after dropping and recreating it

Greetings! I have an application that uses an SQLite database file that may or may not exist when the application starts. At startup, the application creates three tables. If the file previously existed, the create table queries fail. My code checks the error message, and if it indicates

Re: [sqlite] [Delphi] Reading list of tables?

On 11 Aug 2009, at 11:25am, Gilles Ganault wrote: > I'd like to fill a ComboBox widget with the list of tables in a > database file, using the free Aducom wrapper. > > Would someone have some code handy on how to extract this information > from a SQLite database, ie. the equivalent for the CLI

[sqlite] [Delphi] Reading list of tables?

Hello I'd like to fill a ComboBox widget with the list of tables in a database file, using the free Aducom wrapper. Would someone have some code handy on how to extract this information from a SQLite database, ie. the equivalent for the CLI command ".tables". Thank you.

Re: [sqlite] Busy Handler in Shared Cache Mode?

More detailed testing revealed that it is not a reader but the writer who observes a long wait time. The writer appears to get unlocked after all reader-threads have completed. This must be a case of writer starvation. I had not realized that shared cache mode is, by default, prone to this. The