Posit: Unlimited "Undo" in fP?

[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 Fairlight
> Sent: Wednesday, July 25, 2007 9:04 PM
> To: filePro Mailing List
> Subject: Posit: Unlimited "Undo" in fP?
> 
> Well, I was thinking about this from my article when I wrote 
> it late last week.  I had a section on software having Undo features.
> 
> Got me thinking about fP...
> 
> What happens if you take a table on which you're altering 
> data, and @wef* or any other appropriate events, you actually 
> take a "snapshot" of the record into a secondary backup 
> table, complete with an added session and sequence number?
> 
> In this fashion, you could assign some way of triggering an 
> Undo, which would take data from the last sequence number on 
> the stack for that session.  After the session (however you 
> define it...say you have a step that finalises a 
> transaction), you could just delete all "step" records in the 
> backup file for that session number.
> 
> Technically, you could implement Redo as well by keeping a 
> counter of which step you're on and just pulling the sequence 
> number forward instead of backwards, and not deleting -any- 
> records until things are finalised.
> 
> I thought this might be an interesting thing to toss around 
> as an idea for implementation.  Could be handy in some 
> environments/instances.
> 
> Technically, it could be expanded to header/detail as well, 
> obviously at the cost of some (more!) processing.
> 
> Actually, I was thinking it might be painful to have to code 
> new Undo/Redo for each table, but it might be possible to 
> make is modular, as long as you had 997 fields or less in 
> actual use so you have two available.  It's possible to do 
> with special formatting and use only 1 field, I suppose.
> But basically just make a copy of any file you want to have 
> Undo/Redo, and the only thing that needs to change is the 
> lookup name.  The rest of the code could be handled 
> generically with an array laid over the lookup alias, so you 
> just store fields 1-997, period, file agnostically.  Minimal 
> processing rewrite.  I can't think of a way to make it a 
> "true" module since you can't variables lookup file names 
> (to my knowledge).  If you could, I think it'd be possible if 
> you could always guarantee the same index for the one field. 
>  And I -know- you can't use a variable for the index--I've asked.
> 
> Anyone have opinions on this idea or an expansion thereof?  
> It's really just something that occurred to me suddenly and 
> has been an intellectual exercise since then.  If it's useful 
> to someone in some form, cool.
> 
> mark->

I have implemented something like this, but not as detailed for one of my
clients.

His order file is qualified, As order are entered, both the new header and
all detail records are created.

Any time a change is made to the primary file, the backup(history) file is
updated.

On a monthly basis, shipped order details are delegated from the primary
file leaving just the history details.  The delete procedure checks the
history detail file to insure that both records are in sync prior to
deletion.

The header record is left and if <L> is pressed to list the details, the
primary file is checked first, if there are no details, the history file
details are displayed.

Now this is not a roll back but if one is going to implement something like
this, using a qualified file would be easiest.

The other option, which I have done for another client, is to track changes
to specific fields in a file.  All changes are logged to the same log file
showing the field name and field #, the starting value and the new value,
the file name, process, user name and computer name and the time of the
change.

One new addition they requested is tracking changes to the specified fields
with a process in another file.  So, if a status field is changed when a
payment is received by the A/R process, this will be logged also.  I will
need to add this information to the log file data. 

Reporting and data selection will be easy.

Richard Kreiss
GCC Consulting