What could be the cause of RECID pointers corruption/missing? - Forum - OpenEdge RDBMS - Progress Community

What could be the cause of RECID pointers corruption/missing?

 Forum

What could be the cause of RECID pointers corruption/missing?

This question is not answered

Hi All,

Some of my data using RECID pointers randomly went missing. Regret to say that I do not have the database log (.lg ) file for that moment when this incident occurred.

HDD does not have any bad sectors. Database was not touched either. Have done an extensive checking on our application code and highly confident that was not due to application code since the application have been running for number of years with no such issue before.

Kindly advise what could be the cause of this?

Thank you!

All Replies
  • Thomas Mercer-Hursh
    Even then, one has to admit that the real motivation for doing the find using a recid instead of on the three fields or whatever that make up the primary key is laziness in typing

    Actually - no.There are situations where I don't care what record it is or where it comes from in order to "do something to/with it." In other cases the record could be part of a FOR EACH or query result list and doesn't have a "unique" set of fields to get a locked version of the record with. 

  • You have database tables where there is no unique key for the record????

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • yes.

  • If he has them, he's unfortunately not alone with that.

    Always the biggest mess when introducing ProDatasets at customers with legacy DB's...=

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Or the code in question doesn't know what table the record is coming from.

  • Well, I can only hope that this is an inherited schema .... but how can you hope to find the right thing if you don't know the table?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • If the buffer handle is available and I know the record's RECID, then knowing which table it came from or it's primary key becomes irrelevant.

  • @tim: i did not say anything about how often the code might fail, only that it /could/. i know that it does happen because awhile back we had to add some error handling code in the 4GL to handle that case. but as you say, it will be rare. very rare.

    the failure scenario now isn't bad. you just have to handle the case when the row no longer exists and the second find does not return anything. when the rowid has been taken by a row in another table, then the find returns not found instead of the wrong row.

    also, i should have mentioned that the scenario where the third transaction creates a new row for a different table cannot occur if you are using type ii data areas.

    @mike: find current could do the same thing.

    @tmh: nothing wrong with using find by recid in the right circumstances. since a rowid is an encoding of the storage location of the row, we can fetch it directly, without doing an index lookup, which typically involves several additional block accesses.

  • Using the RECID does skip the index lookup.  But that's an awfully skimpy justification.

    --
    Tom Bascom
    tom@wss.com

  • I can see that the bit about partitions is going to be a problem.  Areas and Tenants no issue.  But potential duplication between partitions of a table is almost certainly going to break stuff.  I'm embarrassed to admit that I may have some code that needs remediation.

    On the other hand it isn't like we haven't been warned not to do it for 25 years or so...

    --
    Tom Bascom
    tom@wss.com

  • I seem to remember that some of the internals of the ADM1/2 frameworks passed around the rowid of a record as its unique ID (I might be remembering wrongly though).

    Can anyone remember if this is true?

    if so, does anyone know if the frameworks have been changed to be partition-safe (or are partitions just incompatible with ADM framework).

  • ADM2 batching is based on ROWID‘s
    But as long as you are not switching the tenant I don’t see a problem.
     
     
    Von: andrew.may [mailto:bounce-andrewmay@community.progress.com]
    Gesendet: Mittwoch, 28. Mai 2014 15:22
    An: TU.OE.RDBMS@community.progress.com
    Betreff: RE: What could be the cause of RECID pointers corruption/missing?
     
    Reply by andrew.may

    I seem to remember that some of the internals of the ADM1/2 frameworks passed around the rowid of a record as its unique ID (I might be remembering wrongly though).

    Can anyone remember if this is true?

    if so, does anyone know if the frameworks have been changed to be partition-safe (or are partitions just incompatible with ADM framework).

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Gus said "rows residing in different partitions of a single table can have the same rowid value."

    That (to me) sounded like it would affect a single tenant DB if table partitioning was used.

    Grepping the ADM1 source  for "rowid" shows up a lot of places where the ROWID seems to be used as a unique record id.

  • That’s true. In a multi-tenant scenario.
     
     
     
    Von: andrew.may [mailto:bounce-andrewmay@community.progress.com]
    Gesendet: Mittwoch, 28. Mai 2014 15:28
    An: TU.OE.RDBMS@community.progress.com
    Betreff: RE: What could be the cause of RECID pointers corruption/missing?
     
    Reply by andrew.may

    Gus said "rows residing in different partitions of a single table can have the same rowid value."

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • I thought he means the new announced OE 11.x feature: table partitioning (horizontal).