testing for corruption

Jeff Harrison jeffaharrison at yahoo.com
Wed Feb 6 11:30:18 PST 2008


--- "Brian K. White" <brian at aljex.com> wrote:

[snip]
> Why can't a record be marked for deletion and have
> old data in it?
> How do you know if the 20byte header is wrong or the
> data is wrong?
> 
Because filepro also blanks out the fields in the
deleted records.  So if there is information there you
know that something is wrong - or someone was
modifying something outside of filepro.

> corruption can really only be recognized, let alone
> fixed, by the designer 
> of an _application_ and except in a sense so broad
> as to be not useful, 
> filepro itself doesn't count as an application.
> Fiilepro IS an application 
> and COULD detect some insanity within it''s own data
> structures, such as the 
> file format of a screen or a menu. Filepro is fit to
> automatically say 
> things like "if ever there is a byte foo at this
> location, or if ever their 
> fails to be this repeating pattern from here to
> here... then it is ok to 
> throw it out, zero-fill it, replace it with a valid
> skeleton formatting, 
> whatever etc...
> But the data in a filepro file is just too user
> specifiable.
> 

Such a nitpicker you are.  No, I won't be able to
detect every possible type of corruption.  However, I
will be able to detect where there is non-ascii, or
non-visible ascii characters (other than a space), and
null values.  None of these should exist (in the
filepro data area) in 99.44 % of the applications out
there.

Also, I will be able to detect where the user has
defined data validation via edits and the data does
not pass the edit.  For example if the data for a
Social Security # does not follow the prop ssnum edit.

> You *may* detect that the data doesn't line up with
> the map, *if* you happen 
> to be lucky and the file uses any edits that
[...]

No, I will virtually ALWAYS be able to detect a
mismatch - because there would be a null value in
filepro's data area - remember the 20 byte header will
always contain at least one null value.  So, unless
you have a very small number of records (like 1) this
should be easy to detect.

> garantee certain minimum data 
> must exist, but, even in that lucky case, how do you
> know the which is 
> corrupt, the data, or the map? 

Again, this is not the job of this utility - the
utility would only be designed to let you know there
is corruption.  You'll need to hire one of those high
priced programmers to investigate further :-)
[...]

> The application
> author can say that. No one 
> else can. They know what they wanted.  Which btw, is
> no garantee that's what 
> they told filepro to do. how do you detect
> corruption that is the result of 
> filepro correctly doing exactly what was asked, but
> which was a mistake made 
> by the developer? It's not actually corrupt at all,
> except to the developer 
> who knows he doesn't want it.
> 

If you are talking about a Y/N field containing a "T"
- then yes, the utility would be able to detect this. 
If you are talking about an address containing:
"TERMS: NET 30", then No, that is out of scope for
this utility.
  
[snip]
> Supposed I purposefully put
> edit-breaking data in a field as 
> part of my logic? For whatever reason I want to know
> the difference between 
> emptied-out, never been filled yet, filled but
> invalid, and filled valid?
> Or suppose I count on /ov to alert me that some
> other step has gone out of 
> bounds? The absolute last thing I would want then is
> for my error detecttion 
> to all be erased and made "valid" and leave me never
> suspecting I had 
> errors.
>
[snip]
The edit checking would be optional, so if you don't
want it to check against edits, then don't use that
option.  If you want to allow "/ov" or "/d0" in your
fields that can be an option also.  Otherwise if
non-visible or non-ascii fields existed where they
should not it would be reported - again the 99.44%
rule is used.  Hey, if you store chr("0") or chr("9")
in filepro data fields, then don't use this utility -
or don't use it in any file where that is a
possibility.

Jeff Harrison
jeffaharrison at yahoo.com

Author of JHExport and JHImport.  The fastest and
easiest ways to generate filepro exports and imports.





      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping


More information about the Filepro-list mailing list