Re: [sqlite] promise raid controller uses sqlite ?
Roger Binns wrote: is there really a native java-port of sqlite ? There is an insane project named NestedVM that compiles C code for the MIPS processor and then converts it to Java bytecode. http://nestedvm.ibex.org/ It comes packaged up with a JDBC interface: http://www.zentus.com/sqlitejdbc/ Though I recommend that the platform-dependent version of the driver be used if speed matters. d. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] detect afs, --enable-locking-style, non-darwin fs detection
On 24/12/06, Adam Megacz [EMAIL PROTECTED] wrote: AFS (the Andrew FileSystem) supports whole-file locks but not byte-range locks. Unfortunately, it has a problematic feature whereby it will claim to grant requests for byte-range locks, but not actually perform any locking activity. This unfortunately can easily lead to corruption for applications like sqlite. I would like to see this patch incorporated. AFS seamlessly folds into the unix file system and at the moment I have to remember that it is unsafe to store an SQLite database file on the share. David - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLiteJDBC is now 100% Pure Java
On 14/12/06, Christian Smith [EMAIL PROTECTED] wrote: http://www.zentus.com/sqlitejdbc Is locking now handled by NestedVM so that the driver is useable with native SQLite processes? Yes, that's why it took me so long. :) I have implemented fcntl() locking using java.nio.*, which means it requires Java 1.4 for file locking. Amazingly Java did not support file locking before 1.4 and when they did implement it they made a terrible mistake, reminiscent of closing an FD on fcntl() locks. I believe it can be greatly reduced from the current ~ 800kb, Still, it's smaller than Derby. A head to head might be nice. It can be reduced to ~ 350kb with dynamic interpreter as Joe Wilson suggested, but this will slow it down further. I will do a speed test with derby when I am done with some other nagging bugs. d - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] SQLiteJDBC is now 100% Pure Java
For several months now I have been providing a Java JDBC driver for SQLite 3. Now I am happy to announce with v030, the completion of a 100% Pure Java version. http://www.zentus.com/sqlitejdbc This is accomplished with the support of the great NestedVM project. The SQLite C source is compiled by gcc to a MIPS binary, that is then dynamically interpreted on top of the Java runtime. This involves a performance hit but greatly simplifies inclusion in current projects and delivery cross-platform. The native JNI version has not been abandoned, and binaries are still provided for Windows and Mac OS X. Linux can be directly compiled. The new native version has been extensively tested, with the only major caveat at the moment being the size of the binary. I believe it can be greatly reduced from the current ~ 800kb, I just do not have the time. I hope someone finds this useful. The code is all under a BSD license. d - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Is sqlite, a java wrapper and java for a small app a good solution?
Christian Steinherr [EMAIL PROTECTED] wrote: A few words about the requirements of my application i'm working on: an app with about 5 oder 10 tables, filled with up to 1000 rows of data. It's planned as a singleuser GUI application and i don't think it's becomming very large, maybe 2 lines of code or somthing like this. Java and SQLite will do the job, but whatever language you pick, you will spend very little of the time working with SQLite and most of it working on the GUI. Download Netbeans or Eclipse and play with Java and see if it is to your tastes. d - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Question on JAVA and Sqlite DB
Benedetta.Turchi wrote: which are the recommended JAVA wrapper APIs/JDBC driver to be used to connect to an SQLite DB? I would happily recommend my own, though I may be a little biased http://www.zentus.com/sqlitejdbc There are a list of others on the SQLiteWrappers page of the main wiki. d - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] using auto increment in java
On 12/11/06, Patrick Marchwiak [EMAIL PROTECTED] wrote: I am working on a Java program that uses SQLite for its database. I am using auto increment on some of my inserts and am wondering if there is some easy way to retrieve the auto incremented rowid right after inserting. I realize that there is a C++ function that does just that , but googling did not turn up much for Java. Thanks. Are you using a JDBC driver, if so, which one? I am considering implementing Statement.getGeneratedKeys() using the C API sqlite3_last_insert_rowid() for the driver http://www.zentus.com/sqlitejdbc There may be some issues regarding concurrent connections that will introduce a race condition, but in the simple case it will return properly. d - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] PRAGMA table_info() reveals primary keys
Dennis Cote wrote: You should create a documentation bug ticket so these things will get fixed. Done. -- David - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] PRAGMA table_info() reveals primary keys
I had need of a programmatic interface to determine the primary keys of a table, so I went to add it to pragma table_info, only to discover it is already there. The comment in pragma.c seems out of date, failing to mention the sixth column 'pk', and so is sqlite.org/pragma.html. -- David - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite and McAfee Anti-Virus
On 01/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My efforts to contact Mcafee about this problem have been unfruitful. Does anybody have an suggestions on how I might deal with this? You could trademark the name SQLite and have a lawyer send them a letter. Companies respond much better to that than polite conversation. -- David - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] [OT] Java wrapper binaries for Windows with larget MAX_ARGS
Adriano Rodrigues [EMAIL PROTECTED] wrote: For example, I will miss ResultSet.getObject() which I rely upon heavily. Sorry, the README is out of date there. The latest version v026 supports ResultSet.getObject() by instancing the object that matches the storage type of the column. So you will get either an Integer, Double, byte[] or String. Other parts of the JDBC API are designed for ResultSets other than FORWARD_ONLY. Functions such as previou() or first() will never be supported, as they are not by most simple queries on most databases. d - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] [OT] Java wrapper binaries for Windows with larget MAX_ARGS
Adriano Ferreira [EMAIL PROTECTED] wrote: Does anyone know where I can get binary files for the Christian Werner's Java wrapper (sqlite.jar and sqlite_jni.dll) which allows for a large number of placeholders (something like 256 or so)? If you are just after a JDBC driver with no arbitrary limit on the number of statement parameters, I provide a Windows binary: http://www.zentus.com/sqlitejdbc/ David - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] See table structure
Lloyd [EMAIL PROTECTED] wrote: Hi List, In SQLite, to see the table structure which command can I use? (as in Oracle's desc table name ) You can use select * from sqlite_master; and there is specific information available by the pragma command: http://sqlite.org/pragma.html d - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] freeing pUserData
Roberto [EMAIL PROTECTED] wrote: int sqlite3_user_data_find(...) Usually the user data is some information you can use to refer to your context. How are you using the userData ? I'm keeping a reference to a Java object in it that contains the actual function being called. Woudn't keeping a reference to your userData and freeing it at DB closing time be enough? This was the original plan, but it leads to a lot of effective-memory leak situations with the JVM. Oh well, it was a pretty ugly function anyway, there just isn't a way otherwise to clean up until the connection is closed. - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] compiling 3.3.7 with loadable extensions
The new loadable extensions cause a range of errors compiling the plain-source file, sqlite-source-3_3_7. Not a problem for me as I'm omitting them with -DSQLITE_OMIT_LOAD_EXTENSION, but log is below: $ unzip sqlite-source-3_3_7.zip $ mv tclsqlite.c tclsqlite.c.not $ gcc -c *.c 2log In file included from loadext.c:18: sqlite3ext.h:78: error: parse error before '*' token In file included from loadext.c:19: sqliteInt.h:501: error: parse error before 'sqlite3_vtab' sqliteInt.h:501: warning: no semicolon at end of struct or union sqliteInt.h:512: error: parse error before '}' token sqliteInt.h:582: warning: no semicolon at end of struct or union sqliteInt.h:582: error: parse error before '*' token sqliteInt.h:585: error: parse error before '}' token sqliteInt.h:730: error: parse error before 'sqlite3_vtab' sqliteInt.h:730: warning: no semicolon at end of struct or union sqliteInt.h:735: error: parse error before '}' token sqliteInt.h:1157: error: parse error before 'sqlite3_index_info' sqliteInt.h:1157: warning: no semicolon at end of struct or union sqliteInt.h:1163: warning: data definition has no type or storage class sqliteInt.h:1164: error: parse error before '}' token sqliteInt.h:1180: error: parse error before 'sqlite3_index_info' sqliteInt.h:1180: warning: no semicolon at end of struct or union sqliteInt.h:1181: error: array type has incomplete element type sqliteInt.h:1182: error: parse error before '}' token sqliteInt.h:1870: error: parse error before 'sqlite3_vtab' loadext.c:132: error: 'sqlite3_column_value' undeclared here (not in a function) loadext.c:140: error: 'sqlite3_create_module' undeclared here (not in a function) loadext.c:143: error: 'sqlite3_declare_vtab' undeclared here (not in a function) loadext.c:151: warning: initialization from incompatible pointer type loadext.c:161: error: 'sqlite3_malloc' undeclared here (not in a function) loadext.c:169: error: 'sqlite3_realloc' undeclared here (not in a function) loadext.c: In function 'sqlite3_enable_load_extension': loadext.c:348: error: dereferencing pointer to incomplete type loadext.c:350: error: dereferencing pointer to incomplete type vtab.c: In function 'addArgumentToVtab': vtab.c:142: warning: pointer targets in initialization differ in signedness - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Re: SQLite and Java
Umesh Nayak [EMAIL PROTECTED] wrote: Does SQLite work with Java? Yes. I have written a JDBC driver for SQLite 3: http://www.zentus.com/sqlitejdbc There are also other projects for working with SQLite in Java. See the wiki off www.sqlite.org d
Re: AW: AW: [sqlite] New JDBC driver for SQLite
Martin Pfeifle wrote: could you please shortly outline the differences between your jdbc driver and the one developed by Christian Werner? I haven't looked too closely at the other driver, but from what I have seen, it is designed to work with the old callback exec() functions, so it supports SQLite 2, but is probably slower. I've gone for simplicity with this one. This driver has a lot less code in it. There is a single .c file: http://java.zentus.com/src/sqlitejdbc/src/org/sqlite/DB.java http://java.zentus.com/src/sqlitejdbc/src/org/sqlite/DB.c which basically maps the C functions into Java. The JDBC implementation just calls these functions as appropriate. I also put a lot of effort into making binaries, so it is easy to use. Compiling JNI libraries for different platforms is a bit of a pain. d
Re: RE: AW: AW: [sqlite] New JDBC driver for SQLite
Brannon King wrote: To compile the binary with VC71, I had to 1. move a dozen variable declarations to the top of the function 2. download the DB.h file separately from the build tree 3. change the jstrlen to end with return (int)(s - str) - suppChars 4. change my sqlite3 lib build to #define SQLITE_ENABLE_COLUMN_METADATA 5. reference the sqlite3 lib in a dll project containing the DB.c/h Thanks for the info. Points 2, 4 and 5 are covered by the Makefile (DB.h is generated with javah), but I'll patch the project for the variable declarations and the cast. Though I have a feeling the cast is unncessesary, did VC throw an error or warning for that? I'd be interested in knowing if you've noticed a significant speed improvement. The simplest test would be running test.Test from the source tree. d
Re: RE: RE: AW: AW: [sqlite] New JDBC driver for SQLite
Brannon wrote: It was just a warning. Instructions for MSVC added to the README.
[sqlite] New JDBC driver for SQLite
Hello all, I have written a new JDBC driver for SQLite. http://java.zentus.com/sqlitejdbc.html It is designed to be easy to read and as thin a layer as possible on top of the C functions. The new _prepare()/_step() API is surprisingly similar to the JDBC API, making it efficient code. SQLite is compiled straight into the JNI binary, which keeps things simple for Java programmers. There is only one dll/so/jnilib that needs to be added to a project. I've build binaries for Linux i386, Mac (universal) and Windows. Any testing would be greatly appreciated, I don't have much hardware. My few speed tests so far suggest it is fast. Code like: statement.setAutoCommit(false); for (int i=0; i 1000; i++) statement.executeUpdate(INSERT INTO...); statement.commit(); runs in under 30ms on Linux. This means the JNI bridge is not causing any serious overhead. There are still a couple of features to add. I plan automatic Java date/time handling and the code is not thread safe. These are not difficult to do, I am just distracted by another optimisation right now. The code is under the BSD license. I hope someone finds a use for it. d
Re: AW: [sqlite] New JDBC driver for SQLite
Martin Pfeifle [EMAIL PROTECTED] wrote: Does the jdbc driver also provide the direct reading and writing of BLOBs? Yes, through PreparedStatement.setBytes() and ResultSet.getBytes(). I haven't added support yet for the java.sql.Blob type, because I am funadmentally opposed to the idea of SQL calls generating heap garbage and invoking the GC. One thing I am trying to solve is how to get the size of a BLOB without using RS.getBLOB(). d
Re: Re: [sqlite] New JDBC driver for SQLite
Michael Scharf wrote: I quickly looked at the code -- it's amazingly small! I really like that. I have to do some performance tests to see if it fits my needs.. Thanks. I think you will find the JNI is not a problem, I tested it on its own and the overhead is non-existent. The problem you should test for is String speed. Try using PreparedStatement.setString() and ResultSet.getString() a lot, along with the BLOB equivalents. The memory copying might be a problem. d
