Retreival of serial values

Well, yet another question about serial values. In our VB/RDO/ODBC/Informix Online 7.3 system we used to store unique keys for other tables (about ten of them) in a table and have a stored procedure lock the table, do an update and a select, returning the new 'fake' serial number. This has turned out to be a performance bottleneck with multiple concurrent inserts, so we are thinking about using the dbinfo function in an insert->dbinfo->select->update operation with a SERIAL column instead. Not being an expert at Informix I have this question to the community; Can I guarantee that an insert followed by an select dbinfo('sqlca.sqlerr1') operation will *always* return a unique number for multiple concurrent inserts? I have yet to learn in depth the intricasies of isolation levels, but I figure they might have to do something to do with this. To put it another way, I need to be reassured that no two users can ever get the same SERIAL value from the dbinfo function after two concurrent inserts. Thanks. /Ola

In article <36a37ad0.0@news.sto.telegate.se>, ols@knowit.se says... >To put it >another way, I need to be reassured that no two users can ever get the same >SERIAL value from the dbinfo function after two concurrent inserts. It is guaranteed that a given dbinfo() for a user will return information for the last SQL on that connection. In other words, Informix isn't doing an internal "select max(serial_no) from table"; it's got the serial number. However... Under Visual Basic, it can be difficult to guarantee that the last SQL statement your database control was actually the insert statement. Turn tracing on and look at some of the SQL activity your application is generating - if it is getting "extra" SQL statements after your insert, you may need to use direct calls to the ODBC API to guarantee what statements will be executed when. -- William Harris william@carsinfo.com Check out the NAGS spam filter. http://www.nags.org