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

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!

You have posted to a forum that requires a moderator to approve posts before they are publicly available.

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 posted to a forum that requires a moderator to approve posts before they are publicly available.

@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.

You have posted to a forum that requires a moderator to approve posts before they are publicly available.

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 Bascomtom@wss.com

You have posted to a forum that requires a moderator to approve posts before they are publicly available.