Re: ROWID

Alex@arcfan.demon.co.uk (Alex McLintock) writes: >Someone quite helpfully pointed me at ROWID since >I was after some sort of Record Number. >I am using various SELECT statements and I want the ROWID >for any table's row to remain the same for the entire lifetime >of my program - even if other records in the table are deleted >Is this a correct assumption? NO NO NO NO NO.......Unless you like debugging code in the middle of the night. Here is a peice of E-Mail that went out to a the SE's at Informix a little while ago. It explains everything about ROWID...Yesterday, Today, & Tomorrow. If you have any questions please feel free to post them or E-Mail. Ron Delpiere-Smith, CSE reds@informix.com DISCLAIMER: The above comments are _MINE_ & mine alone. The comments below belong to Marketing.... ------------------------------------------------------------------------------- Date: Tue, 3 May 94 15:04:44 PDT To: tech@violin Subject: Rowid or lack there-of in OnLine 7.0 Cc: <Various Informix Employees> Status: RO May 3, 1994 TECH ALERT FROM MARKETING......TECH ALERT FROM MARKETING...TECH ALERT FROM MAR.. ================================================================================ "WARNING: IF you use table fragmentation in the PDQ release of OnLine and use rowids in your applications you MUST execute one of the two options listed below" ================================================================================ Dear Tech: We, in Menlo Park, are working on the PDQ (Parallel Database Queries) release of the software and need to warn you of possible changes in the future to application programs migrating from INFORMIX-OnLine 6.0 to the PDQ (after 6.0) version of INFORMIX-OnLine when using table fragmentation. How Are Rowids Assigned, when do they change? --------------------------------------------- In pre-PDQ engines, rowids are assigned at the time of record insertion and normally remain static until record deletion. Rowids can change whenever an ALTER TABLE, ALTER INDEX TO CLUSTER, etc. is performed. In PDQ engines, rowid access has changed. If rowid's are used AND they migrate to fragmented tables, users have two choices: 1) They must explicitly create a rowid field. Rowid access is no longer a physical addressing access method. Failure to create the rowid field will result in an error if rowid is referenced. The rowid field can be created at CREATE TABLE, at ALTER TABLE time, or use an option in ALTER FRAGMENT to create a rowid field. OR 2) Change the application to stop using rowids. In general, we recommend that users creating new applications move toward primary keys as a method of row identification instead of using rowids. Primary keys are defined in ANSI and using them will make applications more portable since rowids are not supported by all vendors. If fragmentation is used on the table, and rowid is referenced but an explicit rowid has not been created, the user will receive an error number/message that will be unique and will be generated only in this particular case. So instead of saying "column not found" we'll say "rowids do not exist on table" which exposes the source of the problem more clearly. Insync Group should also starting disseminating this information to our partners. Regards, Shirley Li Rexrode Product Manager, Unix Database Servers