Two parter: rant & wishlist items

[Walter Vaughan]

Courtney wrote:
> Kinda of dangerous tho...if ab (the variable we used) had been defined in
> the automatic processing table (i.e.  ab(6,.0)) then we you compiled the
> processing table a message would pop up telling you ab already defined in
> automatic processing...but since it was not defined in automatic, nothing
> mentioned!

"auto.prc" or "prc.automatic" processing tables are probably taught way 
too early in a filePro developers life. When you use them, they should 
come with a warning label that says, "You know that every record from 
now on in this file will execute this processing table twice per record 
access unless you specifically disable it in a menu command line. 
Perhaps you should rename this table something else, and call it from 
the menu line that executes your application with a -y tablename. If you 
decide to go ahead and make this a global automatic table, be aware that 
unexpected things can happen in applications that you write in the 
future and do not remember to take this automatic table into account." 
And when you save a processing table it should say, "You know, there is 
an automatic processing table for this file. Did you take that into 
consideration when developing this table?".

It could have been worse. You could have wrote data to other records and 
now would have /OV's where there should be good values. So then you have 
to go back to your last backup and hope that you have documentation to 
restore all the differences between the backup and what's current this 
second.

Yikes. I'm scaring myself.

Since filePro has pretty good control of it's native database level, why 
not a few new commands for fp6.0...

xx=FREEZE - [qualifier]
  * creates a backup of current file and optionally names it for use as 
a qualified files as needed

xx=UNFREEZE - [qualifier]
  * restores the current file backup or moves the qualified file into place

I see these commands being used in @once, @menu, @entsel, etc.. type 
locations. Of course "UNFREEZE" is a million times harder to implement 
(what do you do if someone else is standing on an open record?... return 
the @rn of the open record and allow for logical case handling[0]). But 
it could allow for a limited function "roll-back transaction". Actually 
they probably should be named BACKUP and RESTORE.
--
Walter

[0]
restor::xx=unfreeze -
:xx eq "0":goto did_rst
::'add in code from lsof library if this is a problem tracking down
::msgbox "Someone has record#"<xx<"in update mode. Retry?","YN"
:@BK eq "Y":goto restor
:'aborted unfreeze:show"@You have chosen not to restore current file"