× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



A RRN undeleted via an update [I\O request via the QDBUDR] does not recover the old data. That is why the SAVOBJ technique is used to locate and recover data from [fixed-length] deleted records.

The /update/ method provides as input, the desired row image. So although an uncleansed prior /delete/ [i.e. the DENT byte, the Deleted Entry indicator, perhaps being all that was changed to effect the /deleted/ row while leaving any record-data unchanged] might have been the effect, whatever data may have remained there is replaced by the new row image; default values are generated for any fields that were not provided as part of the desired update-to row image.

Note that the variable portion of the record [i.e. the "var SID", the data segment(s) where the VarLen row data is stored] already may not be available in a deleted row. And if a secure\cleansed delete is available and used, so too the data even for the fixed portion would be unavailable; i.e. the SAVOBJ technique would have even more limits in effectiveness as a means to recover row data from a deleted row.

I recall there was a long outstanding request to expose a true undelete method, but I do not think that was ever given much pull. The complexity due in part to undelete not having been a consideration in initial designs [e.g. accpth maint, varlen, and obviously ReuseDlt] and a competing desire for secure deletes [perhaps as a file attribute, set in each dataspace] made that unlikely; but _if_ implemented, would surely be as an /insert/ of the recovered data, and not limited to just some very specific small subset of files, and so very costly to make happen. Backups and journaling were always considered sufficient to recover any deleted row data. And perhaps the lack of undelete gives great incentive to start journal of the physical files; a long outstanding desire that customers would implement, for which enhancements in managing receivers and performance of journaling gave further hope.

Regards, Chuck

On 29-Mar-2012 21:43 , Peter Dow wrote:
"an update to that record makes that row\RRN become an
active\undeleted record."

Can that be used to undelete a record and recover the data that was
in it?

On 3/29/2012 12:34 PM, CRPence wrote:
<<SNIP>> Then because a deleted row can be positioned-to like any
other record when employing "direct" positioning requests, as with
OVRDBF POSITION(*RRN rrn), an update to that record makes that
row\RRN become an active\undeleted record. That capability allows
data copy from an active row to a previously deleted row, as
implementation for reorganizing to compress deleted rows [from the
lower RRN of the dataspace to the end, such that the database can
eventually be truncated of only since-deleted RRNs]. <<SNIP>>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.