I think this should generate a syntax error...whatdoeseveryoneelse think?

Bruce Easton bruce at stn.com
Fri Jan 26 16:16:46 PST 2007


Ken Brody wrote Fri 1/26/2007 4:28 PM:
>
> Quoting Bruce Easton (Fri, 26 Jan 2007 16:00:32 -0500):
> [...]
> > >> Then, when you assign to field 9, which you *know* you just removed,
> > >> it does not complain in any way. No syntax error.  Yes, I see thatthe
> > >> fields are still actually there with the colons and all in the map...
> > >> and they are visible on the F6 screen...
> >
> > to which Ken replied:
> >
> > > Yes.  You have simply made them zero length with no name.
> >
> > Here's where my curiosity gets the best of me.  If when a map is saved
> > with a fewer number of visible fields (not with 0 size, but completely
> > blanked lines), and the operator says yeah, shrink the file when
> > restructuring, why in the world are those extra lines left in the map
> > and therefore be considered assignable fields by processing? (The ones
> > that are left with just colons.)
> [...]
>
> Because there is already data in the file, and filePro will not change
> the field numbering in such a situation.  (That's the same reason that
> you can't use F3/F4 to insert/delete fields from the existing part of
> the map when there is data in the file.)
>

Ken - but we are winding up with no data for such a field that has been
completely blanked out.  And we said yes to shrink the file, so wouldn't it
stand to reason that there is no longer any purpose for the map placeholder
for the field?  F3/F4 makes sense to me because you are providing it as a
useful tool inside ddefine independent of restructuring - so I understand
the protection built in to keep it useful for files with no data.  But I
would think restructuring could include a clean-up of map fields that no
longer have a purpose and where data is being eliminated as part of the
restructure.

I'm not sure if I've tried this before, but I see now that filepro is
consistent on this point whether or not the "newly completely blanked out
fields" are in the middle or at the end of the map.  My concern on this so
far is really only about  the case where filepro is leaving the colons for
completely empty map entries at the end of the logical map (key + any data),
where I wouldn't think any renumbering should have to occur.  But based on
the current behavior, I see that if a map clean-up was added as part of
restructuring, for fields at the end of a logical map, the usage of any
non-blank char in any of the fields, including "0" in the size field would
have to be seen differently by filepro from a completely blank line.

Let me ask this - if there had never been both a key and a data segment, and
only a key segment from the very beginning - do you think that would that
have made a difference in the kind of maintenance that is automatically done
by filepro on the map?

Bruce Easton
STN ,Inc.



More information about the Filepro-list mailing list