I think this should generate asyntaxerror...whatdoeseveryoneelse think?

[John Esak]

<top posted>

I (at least, don't know who else jumped in on this thread) was commenting on
the extra completely empty fields at the *end* of the key segment. Those
empty sets of 3 colons you see in the map if you completely remove the stuff
in Define Files. Don't care about the empty fields between other fields...
just those at the very end of the key.  And I don't really care much about
them either... but, I was just thinking that if yo wanted to know how many
fields were in the file, you might get that larger (incorrect for your
pruposes) number that includes the empty fields at the end of the key....
not the actual number of fields with some lenght to them. Then I realized
that there is the legacy Data segment and nothing can be removed form the
end of the key if it had once been there.   I also realized that just
because the last fields were empty they don't need to have 0's in their
length field to be that way.

Just to be neat, I have occasionally gone into the map and removed all the
extra sets of empty colons FROM THE END OF THEFILE ONLY... and then
subtracted the number of lines I've removed from the nubmer which designates
how many key fields there are in the first line of the map. Things stay the
same and there isn't this extra group of dots in the file. :-)  REally, I
only have done this when I had added 50 or 60 extra fields or 10 sets of
arrays that I ended up not needing or whatever.

Anyway, I don't think anyone wanted the removal of empty fields with the
active fields of the key segment... at least I never did.

My convention by the way is to label empty fields with an "r" for reserved
and then give them a length of 0 for clarity. If the field has no purpose,
but still has length and I want to keep it that way, I label it "spare". AS
in spare 2,0, spare 10,allup, etc.  It's easier to spt what can be used
right away without reshuffling the map and all the data.

Of all the comments I made on this topic, they were all silly actually,
except the main reason for the comments themselves and that is I think it
would be nice if a WARNING was given when a processing table is stored that
alerts you to the fact that you have just made an assignment to a field that
has 0 length and therefore will certainly not do what you think is going to
happen... unless you do somethign about it.

John







> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> Behalf Of Mike Schwartz (PC Support)
> Sent: Saturday, January 27, 2007 4:10 PM
> To: filepro-list at lists.celestial.com
> Subject: RE: I think this should generate
> asyntaxerror...whatdoeseveryoneelse think?
>
>
> > Bruce Easton Wrote:
> > 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
>
>      I must be completely missing the boat on what you are
> asking, because,
> for example, if I were able to completely delete field 25 in my database,
> all of the other numbered fields would move down one field number.  IE,
> field 26 now becomes field 25, 27 becomes 26, etc.  Wouldn't that
> break all
> my processing where I am posting something to field 26 or 27?  Or
> don't you
> ever post data to a numbered field in filePro or reference fields by field
> number in your processing?
>
>      I always assumed this was a reason why we couldn't use the
> F3/F4 key to
> insert or delete a new field.
>
>      Personally, I don't mind the blank fields as place holders.  I have
> written numerous archive applications where I purposely zero out
> the length
> of some fields that aren't essential for my archiving purposes,
> but then use
> a single "copy" command to copy old data to the archive files.  This keeps
> my archive file small.  I'd hate to have to write field by field
> posting for
> each archive process that I write.
>
> Mike Schwartz
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list