Informix

Informix

Connect with Db2, Informix, Netezza, open source, and other data experts to gain value from your data, share insights, and solve problems.

 View Only
  • 1.  Informix 15 negative rowid values???

    Posted Tue December 10, 2024 06:56 AM

    Hi,

    Just installed IBM Informix 15.0.0.0 and started some tests...

    Can someone explain why we get now large negative ROWID values?

    sf@toro:/tmp$ dbaccess -V
    DB-Access Version 15.0.0.0DE
    
    sf@toro:/tmp$ dbaccess test1 -
    Database selected.
    
    > create table tab1 ( pkey integer not null primary key, name varchar(50) );
    Table created.
    
    > insert into tab1 values ( 101, 'aaaa' );
    1 row(s) inserted.
    
    > insert into tab1 values ( 102, 'bbbb' );
    1 row(s) inserted.
    
    > select rowid from tab1;
                   rowid 
    -9223372036854710271
    -9223372036854710270
    1 row(s) retrieved.
    

    Detected while executing our non-regression tests with Genero BDL.

    Is this documented somewhere ?

    Seb



    ------------------------------
    Sebastien FLAESCH
    ------------------------------


  • 2.  RE: Informix 15 negative rowid values???

    Posted Tue December 10, 2024 07:28 AM

    Sebastien:

    Yes, the ROWID will show as negative. It is now a 64bit number with the high bit turned on, so it will show as negative. That is "working as designed", not to worry.

    Art



    ------------------------------
    Art S. Kagel, President and Principal Consultant
    ASK Database Management Corp.
    www.askdbmgt.com
    ------------------------------



  • 3.  RE: Informix 15 negative rowid values???

    Posted Tue December 10, 2024 08:45 AM

    Ok thanks for clarifying, Art!

    The 64bit integer ROWIDs can affect legacy *.4gl code using INTEGER to hold such information.

    I have seen many implementations of record list management code using ARRAY[] OF INTEGER to store a result set of rowids as unique/pkey.

    I believe I4GL has no BIGINT data type right?

    So the best option would be to use DECIMAL(p,0) to store ROWID values.

    Seb



    ------------------------------
    Sebastien FLAESCH
    ------------------------------



  • 4.  RE: Informix 15 negative rowid values???

    Posted Tue December 10, 2024 08:56 AM

    Sebatien:

    Yes, DECIMAL would be the best bet in 4GL for now. IBM has committed to updating 4GL and ISQL to handle all of the changes to v15.0 that are affecting 4GL apps. No release date yet, but those will be updates to the 7.51 (aka latest) 4GL and ISQL releases, not version updates but "fix" level releases and not any kind of v15 versioning change ala CSDK.

    The alternative would be to move your code to Querix Lycia or 4Js Genero which, I believe - but check - are v15 ready now. Not sure of Mike has Aubit updated for v15.

    Art



    ------------------------------
    Art S. Kagel, President and Principal Consultant
    ASK Database Management Corp.
    www.askdbmgt.com
    ------------------------------



  • 5.  RE: Informix 15 negative rowid values???

    Posted Tue December 10, 2024 08:58 AM

    Also, note that some fields in sqlca and sqlda structures that were long int are now 64bit ints, so even if you code to DECIMAL for rowids, there will still be issues with the library mismatch on those structures which 4GL uses under the hood.



    ------------------------------
    Art S. Kagel, President and Principal Consultant
    ASK Database Management Corp.
    www.askdbmgt.com
    ------------------------------



  • 6.  RE: Informix 15 negative rowid values???

    Posted Tue December 10, 2024 09:19 AM

    About sqlca/sqlda structures:

    Yes, we have already seen this change, and we have adapted our code to support Informix 15 CSDK in a future version of Genero BDL.

    Seb



    ------------------------------
    Sebastien FLAESCH
    ------------------------------



  • 7.  RE: Informix 15 negative rowid values???

    Posted Wed December 11, 2024 11:31 AM

    Also note that you'll see some negative rowid values in v14 and all earlier versions if the (non-fragmented) table contains more than 8,388,607 (0x7FFFFF) pages. Select hex(rowid) in all versions for a saner look. In fact the "meaning" of an internal rowid is revealed only in hex.

    Large rowids in v15 are always negative when displayed as signed decimal values, because for them the 0x8000000000000000 bit is always on. This is how we distinguish legacy 4-byte rowids from large rowids. Internally rowids of both formats are shipped around in 8-byte containers and we needed a sure-fire way to tell them apart.



    ------------------------------
    John Lengyel
    ------------------------------



  • 8.  RE: Informix 15 negative rowid values???

    Posted Wed December 11, 2024 01:16 PM
    Edited by Sebastien FLAESCH Thu December 12, 2024 02:41 AM

    Hi John!

    Thanks for the tip about using HEX(ROWID) .

    Not sure to get why you have to distinguish 4-byte and 8-byte rowids, but it's out of scope for me.

    My concern is about existing .4gl code using INTEGER to store rowid values.

    I have adapted our QA test (for Genero BDL) which is doing a:
    SELECT rowid INTO myvar FROM tab1 WHERE ...
     followed by an:
    UPDATE tab1 ... WHERE rowid = myvar

    Changing
    DEFINE myvar INTEGER
    to
    DEFINE myvar BIGINT
    did the job.

    Seb



    ------------------------------
    Sebastien FLAESCH
    ------------------------------



  • 9.  RE: Informix 15 negative rowid values???

    Posted Wed December 11, 2024 11:52 PM

    Yup. That'll do it.

    Now, because I know you're secretly curious why we have to distinguish between legacy and large rowids, I'll explain that here.

    As I said earlier, an internal rowid value only makes sense in hexadecimal format. It's a code that contains two separate pieces of info: a page number, and a slot number. When displayed in hex, the format of a legacy 4-byte rowid is this:

    PPPPPPSS

    Where PPPPPP is the page number and SS is the slot number. So let's say you had this legacy rowid:

    0x0000AB01

    That would mean the associated row was on page 0xAB, in slot 0x01. In the legacy rowid we devote only one byte for the slot number, which is why we can't address more than 255 rows on a page when using these rowids.

    Large rowids are bigger obviously, but they also have a different format:

    PPPPPPPPPPPPSSSS

    Devoting 2 bytes to the slot number allows us to address up to 64k slots on a page, while still leaving plenty of bytes for the page number.

    Internally both types of rowid are shipped around in the same 8-byte containers. So let's say a 'rowid' variable in our source code contained this value:

    0x000000000001BF02

    Interpreting that as a legacy rowid, that would be page 0x1BF, slot 2.
    Interpreting that as a large rowid, that would be page 0x1, slot 0xBF02.

    Quite different.

    So we need to know for sure whether this is a large rowid or a small (4-byte) rowid we're dealing with. We do that by checking whether the value contains the most significant bit: 0x8000000000000000.


    The correct small rowid for a row on page 0x1234, in slot 5, would be 0x0000000000123405.
    The correct large rowid for a row on page  0x1234, in slot 5, would be 0x8000000012340005.

    Note that although our large rowid format allows for 64k slots per page, our current max page size of 256k can hold only  ~30,000 of the smallest possible rows. If there is demand for larger page sizes in the future our new architecture could support them.



    ------------------------------
    John Lengyel
    ------------------------------