Re: A way to get autogenerated keys

Posted in 2006

bozon — 16 Dec 2006 06:49:15 -0800 — source: Usenet: comp.databases.informix

It is all there the media center is very complete and very good. Doug Lawry wrote: > Well found! I didn't know Client SDK and JDBC were covered in the Infocenter. > > "bozon" <curtis@crowson1.com> wrote in message > news:1166107197.017917.88770@80g2000cwy.googlegroups.com... > >I copied this FTFM (From The Fine Manual): > > > > If you execute the getSerial() or getSerial8() method after a CREATE > > TABLE statement, the method returns 1 by default (assuming the new > > table includes a SERIAL or SERIAL8 column). If the table does not > > contain a SERIAL or SERIAL8 column, the method returns 0. If you assign > > a new serial starting number, the method returns that number. If you > > want to use the getSerial() and getSerial8() methods, you must cast the > > Statement or PreparedStatement object to IfmxStatement, the > > Informix-specific implementation of the Statement interface. The > > following example shows how to perform the cast: cmd = "insert into > > serialTable(i) values (100)"; stmt.executeUpdate(cmd); > > System.out.println(cmd+"...okay"); int serialValue = > > ((IfmxStatement)stmt).getSerial(); System.out.println("serial value: " > > + serialValue); > > > > Here is the online link: > > http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.jdbc.doc/jdbc118.htm > > > > Salch, Chris wrote: > >> I need a way to find an auto generated key after an insert statement. I'm > >> working with informix 9.40.HC5 on an HPUX box and have tried the following > >> query, which works quite well on an informix 10 test machine: > >> > >> select dbinfo('sqlca.sqlerrd1') from systables where tabname='systables' > >> > >> Unfortunately, it always returns 0. I've tried this with dbinfo('serial8'), > >> tabid=1 and several combinations of these. Nothing has worked for me yet. > >> > >> Any suggestions? > >> > >> (If there is a nice way to get the ibm jdbc driver to return it's keys > >> according to the jdbc standard and not some obfuscated method I would gladly > >> settle for that :)