RE: informix 4gl and sql 7.x and rowids

Take heart, it wasn't a total waste of time. One of the main issues is that for fragmented tables rowid is no longer unique. (I believe this is correct, if not I'm sure someone will correct me.) Also they're no longer sequential, but generated based on the table's partnum (RTFineM) If it makes you feel any better we did a half ass job of removing rowid's from our code and ran up against a problem. When you alter a table in 7.x informix uses 'alter in place'. Basically this means that informix does nothing to the individual rows until you update them at some later time. I'm not sure exactly why, but when you update a row for a table that is being altered in place, the rowid changes! So here we were with an update cursor based on rowid. We would update the row, and then read it back into the program variables, only to get a status of NOTFOUND. The solution was easy enough. Simply update every row in the table with something like set col1 = col1; However it took us several days with informix tech support to discover what was happening. In the end, you'll probably be glad you took the time to alter your code. You'll also probably find yourself sneaking in a rowid query every now and then when nobody's looking. Sometimes it's still the quickest solution, just don't quote me :-) -----Original Message----- From: DSL [SMTP:dsl@one.net] Posted At: Wednesday, July 07, 1999 4:00 PM Posted To: Informix Conversation: informix 4gl and sql 7.x and rowids Subject: informix 4gl and sql 7.x and rowids during the process of upgrading from 3.x to 7.x, we spent a lot of time removing all refs to rowid, as we were told that rowids were no longer supported ( unless the table was created "with rowid"). i just created a test program on our 7.x system selecting a record and its rowid, then updating the record "where rowid = variable_name", and, to my surprise, it worked!!!. whats the deal here? did we waste all our time removing these pesky varmints?