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?
Thomas Mercer-HurshEven 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
Architect of the SmartComponent Library and WinKit
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?
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.
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...
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).
this post as spam/abuse.
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.
I thought he means the new announced OE 11.x feature: table partitioning (horizontal).