Data corruption

[Kenneth Brody]

Quoting Don Coleman (Wed, 12 Dec 2007 14:29:48 -0500):
[...]
> Updating the record, then saving the record does allow record deletion.
> Thank you.
>
> Next question.  If I am displaying one of the corrupted records on the
> screen, each field appears to contain a straight line similar to the
> graphics characters in dscreen & dmoedef.

If it's the horizontal line, and this is Windows (which you said it was),
then that's a binary zero -- CHR("0").  That fits with the symptom of the
record being seen as unused, which would be marked by the first byte in
the header being zero.

>  So I'm thinking I can write a
> clerk process to update, then save, then delete these records.

Just remember that, being deleted records, you can't select them via the
normal methods.

>  Next task is
> to make sure I correctly identify the corrupted records in the file.  To
> test (not a complete test) I check each position of an 8 character * edit
> field where each position should range from 0-9.  Again, the screen displays
> a graphic dash.  Yet if I run a report with the debug on and I display the
> value contained in this field I get 00000211.  Why does the debugger display
> something different than the screen?  This wouldn't be so bad except this
> file contains 1.6M records.  One at a time may take a while.

How did you get to the record in a report?  If the header marks the record
as deleted, no selection set (not even the "-a" flag) will select it.

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com