I was asked, but...
There really isn't anything for me to add, beyond commenting that if you
can find an alternative to ROWID operations, you probably should.
Also, the ROWID column in a fragmented table is a real, physical column;
it occupies real disk space, unlike the virtual ROWID column in
non-fragmented tables, both in the table and in an index on the ROWID
column.
Yours,
Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>
}Date: Thu, 22 Aug 1996 09:39:39 -0700 (PDT)
}From: Robert Minter <rob@dssmktg.com>
}X-Informix-List-Id: <list.11123>
}
}* We all know that if the applications use rowid in them, then deploying them
}* on the DSA can cause problems due to table fragmentation as each fragment
}* would have its own set of rowids.
}
}I don't know why everyone is misled on this rowid thing. It's not that
}there will be non-unique rowids due to fragments. It's that there will
}NO LONGER be rowids accessible to programs/tools for fragmented tables,
}unless you specifically build the table WITH ROWIDS. Then, you will
}have the uniqueness as you did back in previous versions. Of course,
}now with some minor overhead.
}
}[...]
}
}Any help with this one, Mr. Leffler?