Re: [sqlite] Retrieving ROWID value on duplicate conflict
> Naveen, > > There is no way to do what you want directly in SQL. You are looking for an > INSERT OR UPDATE type of functionality, this does not exist in SQL. > > Your program can retrieve the rowid of a conflicting insert by doing a select > before the insert. If there is a conflicting record then it can be deleted, > and > a new record with the same rowid value can then be inserted. You can wrap > this > series of SQL statements in a transaction to make it atomic. > >do begin >conflicting_row = do select rowid from t where >if conflicting_row >do delete from t where rowid = conflicting_row >do insert into t(rowid, ...) values(conflicting_row, ...) >do commit > > After this sequence, the correct value will be returned by > last_insert_rowid(). > > HTH > Dennis Cote Dennis, Thanks for the information. This is exactly what I needed and works as expected. - Naveen Nathan
[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
[sqlite] Way to "Bind" Columns in Prepare
Of course. Thanks.
AW: [sqlite] New JDBC driver for SQLite
Does the jdbc driver also provide the direct reading and writing of BLOBs?
Best Matin
- Ursprüngliche Mail
Von: David Crawshaw <[EMAIL PROTECTED]>
An: sqlite-users@sqlite.org
Gesendet: Sonntag, den 30. Juli 2006, 14:56:18 Uhr
Betreff: [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: [sqlite] New JDBC driver for SQLite
Hi David,
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..
Michael
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
--
http://MichaelScharf.blogspot.com/
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
[sqlite] Files required to be changed to handle different file system
Hi, I am porting SQLite to DVD, I am using the harddisk which uses our own file system. Can I know which are the files and API's to be changed for reading and writeing the database on to the disk. Thanx in advance, Regards, Vivek R
