System date behavior wish (GRX)

[Bruce Easton]

Chris Sellitto wrote on Monday, February 12, 2007 9:20 AM:

[..]  
>> I was wondering how difficult it would be 
>> to have the @system date fields retain their values upon copying 
>> new records.  I know it would be just as easy carrying a date 
>> field on the record, but I feel this is an inefficient way of 
>> doing things, not to mention a waste of field space.  We archive 
>> our data here on a regular basis, and having this option would be 
>> great.  Maybe have a new flag on the copy command that would 
>> instruct filePro to retain its system dates (@cd, @ud, @bd).
[..]

Dave Snyder wrote:
[..]
> Or and alternate to the copy command such as "archive" that
> would allow that behavior.
[..]

When is a copy not a copy? (Or, when a copied record is not 
re-fp-stamped, but then  modified in the forest - does anyone 
know?)

I like Dave's suggestion above of having an archive command 
that acts like a copy and doesn't alter system-fields.  But 
even then, what would be the rules?  Does the target record have 
to have the same layout?  Maybe instead of an archive command, 
the lookup itself should be denoted in some way as having an 
archive target so that individual field posting is not allowed 
from that lookup (or maybe there should be options, since some 
might argue:

Then:copy targlookup
Then:targlookup(xxx)=yyy
Then:close targlookup

should always give the posted "targlookup" record new system 
fields, yet some might say they just want the option of telling 
filepro explicity what should be allowed and whether or not the 
sys-fields should be reset.)

Of course some might argue that if developers suddenly had
access to sys-field values, then some existing businesses 
where developers are also end-users (and where no one there 
currently knows the aforementioned method of preserving the 
sys-fields) could claim that their records update history has 
been circumvented.  So maybe an upgrade that has such a feature 
should come with a warning.

It would be nice, though, to have this feature for archiving 
purposes.  Also for archiving records, I would like even more 
a built-in quick way to shrink away deleted records.  I'm sure 
this has been requested before.

I regularly try to store my own fields that parallel system 
fields and to prohibit end-user access to them. 

Advantages: go ahead and store 10-dig dates; new fields you 
may want such as create time, update time; your own control 
of when you may and may not want any of these updated (i.e., 
your own batch update field(s) - you could have separate ones 
for specific tracking).

Disadvantages: more space (this has almost never been a problem 
and you may get around it with use of sibling records in 
those rare cases); reliance of code to set fields vs. just 
filepro even w/no processing.  On a system where end-users can 
easily access data files without running intended processing, 
then these developer-sys-fields obviously cannot be considered 
reliable.  


Bruce

Bruce Easton
STN, Inc.