B
Bill Wood
Guest
I will let others reply to points 2 and 3 but point 1 is wrong Rowid is unique. Two records in different partitions cannot have the same rowid. What is true is that if a record is moved from one partition to another (because you change a field used In a List or range policy) then thay record gets a new ROWID. The ROWID actually contains an encoding of the partition identity -- so it will be globally unique. Sent from my iPhone On Oct 10, 2014, at 8:20 AM, "RWEBSTER" bounce-stigdarkstar@community.progress.com wrote: Rowid vs Table partitioning Thread created by RWEBSTER https://community.progress.com/community_groups/openedge_rdbms/f/18/t/10429.aspx?pi20882 The discussion in this thread from a few months ago touched on the subject of using ROWIDs in ABL code in conjunction with table partitioning. There's a lot of discussion there over what would and wouldn't work but the facts I was able to boil down are this: rows residing in different partitions of a single table can have the same rowid value. ADM1 uses rowids as record identifiers for navigation and update and cannot be considered "partition-safe". (I know it's ancient, but it's pertinent to me) (re)finding a record by rowid (FIND-BY-ROWID) might be ok due to some behind the scenes wizardry. So; PHB has asked me to investigate 'partition-proofing' the codebase. We have 2 main elements: ADM1 legacy application (probably not safe to use with partitioning, and I'm ok with that, as it's in drastic need of modernisation) and a newer (cooler) set of OO programs (which use FIND-BY-ROWID in a few places to upgrade locks etc). 2 questions: 1) Are my 3 bulleted points above correct? 2) Are there documented uses of ROWID that *were* ok, but now could fail in conjunction with table partitioning? (Aside from the ADM stuff) Stop receiving emails on this subject. Flag this post as spam/abuse.
Continue reading...
Continue reading...