Connection_lastRowId on postgresql
Paul J Stevens
paul at nfg.nl
Thu May 1 11:04:16 CEST 2008
Jan-Henrik Haukeland wrote:
> On 25. april. 2008, at 14.34, Paul J Stevens wrote:
>
>> Following up because my work-around fails for sqlite.
>>
>> The work-around entails using the 'RETURNING id' clause for
>> postgres, using
>> executeQuery for INSERTs on tables with auto_increment primary keys,
>> and using
>> the returned ResultSet to retrieve the new id if
>> Connection_lastRowId fails
>> (with postgres).
>>
>> This does the job for postgres and mysql, but alas, sqlite fails.
>>
>> test program attached, as always.
>>
>> Any ideas?
>
> Hi Paul, yes I have a couple of ideas,
>
> 1) To enable auto increment in SQLite, use AUTOINCREMENT and create
> your sqlite table like so,
>
> create table test (id INTEGER PRIMARY KEY AUTOINCREMENT, data blob NOT
> NULL);
That is not quite correct. Use of the autoincrement keyword only affects
the algorithm used to select the next ROWID. As long as a field is
INTEGER PRIMARY KEY, that field is used and will automatically contain a
new unique ROWID value.
http://www.sqlite.org/autoinc.html
>
> 2) There is a bug in your test code. If you use
> PreparedStatement_execute() instead of
> PreparedStatement_executeQuery() it works as expected. Enclosed
> working fixed test program for SQLite.
That was my point. I *need* to used executeQuery to enable the postgres
work-around. Remember that my code needs to work for all backends. Using
executeQuery works for both postgres (using the returned resultset) as
well as for mysql (getting lastRowId directly).
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
More information about the libzdb-general
mailing list