Re: rowid no longer unique?
Posted in 1996
It is not quite so simple as ROWID is no longer unique.
If a fragmented table is created, then (by default) there is no ROWID
available at all on that table. This is because if it was made available,
it would not be unique -- the same rowid could exist in each of the
dbspaces into which the table was fragmented. (Internally, the ROWIDs are
stored with a FRAGID to identify the fragment in which the data is stored,
but the FRAGID is not available externally.) However, you can also create
a fragmented table WITH ROWIDS, in which case there is a physical column
(as opposed to the traditional virtual column) called ROWID which cannot be
updated. The values in this column are guaranteed to be unique for the
whole table -- at the expense of 4-bytes per row, some processing during
INSERT, plus an index on the ROWID column (which is probably a
non-negligible overhead if the table is big enough to need fragmenting).
So, you should avoid using ROWID in your code because it won't work for
every table in OnLine 7.x and above.
Note that SE is not affected, and neither are non-fragmented tables, so you
have to go out of your way to break your code by making fragmented tables.
A simple upgrade from, say, 5.0x OnLine will not break your programs.
Yours,
Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>
>From: RonCichoski@msn.com (Ron )
>Date: 31 May 96 21:44:23 -0700
>X-Informix-List-Id: <news.24511>
>
>I think I remember seeing something in this bb about rowid no longer being
>necessarily unique within a table for v7. Is this true? More than once,
>while coding with ESQL, I coded a singleton select that I knew would return
>more than one row so I just added a where clause to avoid opening a cursor:
>
> select col from tab where rowid =
> (select max(rowid) from tab where key = "somevalue")>
>Some purists might say that the model is not properly constructed if I have
>to do this but sometimes when you are dealing in the real world, well....
>
>So, is it true? Thanks in advance.
>
>Ron Cichoski
>rcichoski@adventcon.com