Data corruption

[Don Coleman]

  _____  

From: Wally Turnbull [mailto:wally at tbull.com] 
Sent: Thursday, December 13, 2007 11:05 AM
To: 'Don Coleman'
Subject: RE: Data corruption

 

Don,

 

The suggestion a couple of folks mentioned about using a non-filepro map to
examine the data is a good idea if you now what they are talking about.
That may not be something you have had need of before.  In case you are not
clear about what they mean this is how it works:

 

1. You define a new filePro file - call it "Verify" (for example)

2. During the create process define it as a non-filepro (alien) file

3. Give it the name and path of the key of your corrupt file  
(c:\filepro\badfile\key as a DOS example).  In this case you actually use
word KEY which is the name of the file not the directory

4. Define the file exactly like the badfile map except that you add a
variable
at the beginning (field-1) that is 20 bytes long of type *.

5. All of the fields in Verify will be numbered one higher than they are
in badfile but as long as you keep that in mind it is not a problem.

6. Also the first record in verify is a system record that must not be
changed.
This means that the record numbers in verify will be one higher than in
badfile.  Again not a problem as long as you keep this in mind.

7. Don't change anything in verify field-1 as that will corrupt the source
data.

8. Blank/deleted records in badfile should have a blank field-2 in verify

9. Corrupted records in badfile are likely to contain characters outside the

usual alphabet and numbers. You can check for that with the command
If 2 lt chr("32") or 2 gt chr("126") then @rn minus one in badfile contains
bad data
if 3  lt chr("32") or 2 gt chr("126") then @rn minus one in badfile contains
bad data
etc. repeat for all fields
remember not to check record 1 or field 1 this way as they contain system
information.
By checking the other records and fields where user data is saved you can
test everything
fairly quickly and accurately.

This is probably the best way to check out the records and not miss
something that may not even be obvious by looking at it on screen.  If you
need more help.  Let me know.

 

Peace,

Wally Turnbull

 

> 

> Yesterday I thought I had just run a simple listing from dreport with the

> debugger on.  However, when I tried to replicate this today it doesn't

> select record #13 from a selection set nor does it select it when put into


> a select table.  So you're your premise is correct.  Is my only option

>looking for bad data on a manual view screen?

 

Brian:

> How many times does someone have to say "map a non-filepro file over the
key" ?

 

 

Thank you Wally.  I've never had need to do this before and you provided the
roadmap.  Much appreciated.

Don Coleman
Donald G. Coleman, Consultant
402 Andrew Circle
Indiana, PA 15701
dcoleman at dgcreact.com
(724) 349-6302 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20071213/4d8b465f/attachment-0001.html