Last Record Update Time?

[GCC Consulting]

> -----Original Message-----
> From: 
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial
> .com 
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
> elestial.com] On Behalf Of Bruce Easton
> Sent: Wednesday, December 12, 2007 11:28 AM
> To: filepro list
> Subject: RE: Last Record Update Time?
> 
> Joe Chasan Wednesday, December 12, 2007 10:24 AM:
> >
> > On Wed, Dec 12, 2007 at 09:37:45AM -0500, Walter Vaughan wrote:
> > > Larry S. Weaver Jr. wrote:
> > > 
> > > >>>I know that @ud gives the date a record was last updated.  
> > Is there a
> > > >>>(perhaps undocumented) system maintained variable containing
> > the time a
> > > >>>record was last updated?
> > > >>>      
> > > >>>
> > > >Anybody think it's worth a wish list item?
> > > >  
> > > >
> > > While there is unused bits in the record header, I don't think
> > there are
> > > enough bits to hold a time stamp.
> > > Do you think fp6.0 should use different file formats would be the 
> > > primary question to solve.
> > 
> > @bd having to mess with @ub instead of having corresponding @bb @cd 
> > with no creation time @ud with no update time @bd with no "batch" 
> > update time file user edit limit
> > 
> > All items that have been asked for many times over the years that 
> > wont' fit in whatever is remaining in the few unused bits of the 
> > record header - i think its time to break with the old and add some 
> > functionality that has been asked for for years.
> > 
> > > And even then to what resolution? MySQL holds resolution to 1 
> > > second, while postgreSQL holds it to a thousanth, MS-SQL 
> is 1/300th 
> > > of
> > a second,
> > > and Oracle is configurable AFAICT.
> > > 
> > > I've been working with systems lately that break in MySQL
> > because of one
> > > second resolution...
> > 
> > that's ken's headache, once we beat fp-tech over the head 
> with a stick 
> > to convince them feature is worth having to begin with.
> >  
> 
> I prefer to store create/udpate dates, times and operator IDs in 
> real fields.  I just find it provides flexibility.  Functionally, 
> with stored fields I can tailor these kinds of fields to more 
> closely match the way in which I think the data may be analyzed. 
> 
> For instance, when I see the lack of a last batch update time, 
> I know that what I would really like is a specific field that 
> shows when a particular posting process had hit a record, regardless 
> of other output processes that may have hit the record (i.e., that 
> may have been designed by someone else, writes the record for 
> some other purpose), ergo the need for a specific store field 
> to track my specific.  We've all probably had to, at one time 
> or another, add that type of field to a file - like "Last 
> Purchase Date".   So why not store all fields that may be needed 
> for an application that may or may not now have a less 
> meaningful counterpart in fp's sys-maintained fields?
> 
> Plus, if someone gets to your application data and archives it 
> in a brute-force manner - poof!
> 
> Now if filepro is not meeting your requirements regarding 
> precision for times, that's another matter that to me 
> seems unrelated to relying on a set of system-provided 
> fields.
> 
> Bruce
> 
> Bruce Easton
> STN, Inc.

Also remember that the windows version of FP doesn't have the same level of
system maintained fields as the &nix versions.

I have since dos days had to have created by and updated by fields and a few
others, per Bruce's notes.

This avoids the problems of archiving date and keeping this information
intact.

Richard Kreiss
GCC Consulting