Last Record Update Time?

[Bruce Easton]

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.