Retreival of Serial Value Following an Insert
Posted in 2000
Topics: Connectivity: ODBC / JDBC / .NET, Connectivity: ESQL/C, 4GL & Embedded SQL
When a record is inserted into the database and Informix assigns the serial value, that value is made available via the sqlda structure when using esql. What is the equivalent mechanism when using the ODBC driver? Thanks! -- Jake Colman Principia Partners LLC Phone: (201) 946-0300 Harborside Financial Center Fax: (201) 946-0320 902 Plaza II Beeper: (800) 928-4640 Jersey City, NJ 07311 E-mail: colman@ppllc.com E-mail: jcolman@jnc.com web: http://www.ppllc.com microsoft: "where do you want to go today?" linux: "where do you want to go tomorrow?" BSD: "are you guys coming, or what?"
Jake Colman wrote: > When a record is inserted into the database and Informix assigns the serial > value, that value is made available via the sqlda structure when using esql. > What is the equivalent mechanism when using the ODBC driver? Umm, actually through the sqlca structure (sqlda is the descriptor structure for dynamic SQL bindings). In ODBC, like SPL, you can use the DBINFO function to retrieve the sqlca.sqlerrd[1] value, thus: SELECT DBINFO( 'sqlca.sqlerrd1') FROM systables WHERE tabid = 99; Art S. Kagel
>>>>> "ASK" == Art S Kagel <kagel@bloomberg.net> writes: ASK> Jake Colman wrote: >> When a record is inserted into the database and Informix assigns the >> serial value, that value is made available via the sqlda structure >> when using esql. What is the equivalent mechanism when using the ODBC >> driver? ASK> Umm, actually through the sqlca structure (sqlda is the descriptor ASK> structure for ASK> dynamic SQL bindings). In ODBC, like SPL, you can use the DBINFO ASK> function to retrieve the sqlca.sqlerrd[1] value, thus: ASK> SELECT DBINFO( 'sqlca.sqlerrd1') FROM systables WHERE tabid = 99; Is it 'tabid=99' or 'tabid=1'. I've been told both. Maybe it doesn't matter? -- Jake Colman Principia Partners LLC Phone: (201) 946-0300 Harborside Financial Center Fax: (201) 946-0320 902 Plaza II Beeper: (800) 928-4640 Jersey City, NJ 07311 E-mail: colman@ppllc.com E-mail: jcolman@jnc.com web: http://www.ppllc.com microsoft: "where do you want to go today?" linux: "where do you want to go tomorrow?" BSD: "are you guys coming, or what?"
Jake Colman <colman@ppllc.com> wrote in message news:76k8hv1dpa.fsf@ppllc.com... > >>>>> "ASK" == Art S Kagel <kagel@bloomberg.net> writes: > > > ASK> SELECT DBINFO( 'sqlca.sqlerrd1') FROM systables WHERE tabid = 99; > > > Is it 'tabid=99' or 'tabid=1'. I've been told both. Maybe it doesn't matter? You're right, it doesn't matter. The WHERE clause is just to make the query return only one row. You could select it from anything that you know is reliably present and unique. Using systables WHERE tabid = 1 is fairly traditional for this because you can safely expect there to be always a table 1 (1 to 99 are reserved for Informix, user tables start after that). We're using DBINFO now (thanks to c.d.i) with no problems in our Java programs. -- Andrew Pearson "exactly what the web needs less of"
Jake Colman wrote: > >>>>> "ASK" == Art S Kagel <kagel@bloomberg.net> writes: > [...] > > ASK> SELECT DBINFO( 'sqlca.sqlerrd1') FROM systables WHERE tabid = 99; > > Is it 'tabid=99' or 'tabid=1'. I've been told both. Maybe it doesn't matter? It doesn't matter these days, but once upon not so very long ago, there was no system table with tabid of 99, whereas there has always been a system table with tabid of 1, so I'd regard 1 as more reliable. On the other hand, I'm just an old fuddy-duddy sometimes. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v1.00.PC1 -- see http://www.perl.com/CPAN #include <disclaimer.h>