@ub and @cb issues - an idea

[GCC Consulting]

-----Original Message-----
From: filepro-list-bounces at lists.celestial.com
[mailto:filepro-list-bounces at lists.celestial.com] On Behalf Of Kenneth Brody
Sent: Wednesday, April 21, 2004 12:12 PM
To: Steve Wiltsie
Cc: filePro Mailing List
Subject: Re: @ub and @cb issues - an idea

Steve Wiltsie wrote:
[...]
> But I know my customers that are using the Windows version of filePro 
> would really like to be able to have those system variables available 
> to them as they are in the Unix versions.
[...]

@ID is available under Windows as of 5.0.12.

-----------------------------------------------------------------------
Native version:

Unless I am incorrect, @id is showing the value of the current "username" and
not necessarily the person who created or modified the record.

It is still necessary, if one wants to track that information, to create real
fields to hold that information.

This, IMHO, is a far easier solution to who did what, when, then system fields
which depend on an outside source.

Just look at this thread regarding moving data from one *nix system to another.

Storage has become relatively "inexpensive" and adding the necessary fields to
hold specific information wanted, will not tax even large systems storage space
to any great extent and a easy to program.

I wrote a physician's credentialing system which required much more tracking of
who did what & when then even the *nix system maintained fields offered.  It
took a separate file(s) to track the information management wanted as to who did
what & when.  This included who looked or printed information(when by date &
time) and 10 levels of modification tracking (complete "secret" copies of
before(when "<U> was pressed & after snapshots of the data).  Too much
information to just track the change.  It took 12 screens to get all of the
data.

The above system had it's own login file controlling access to the system.  One
set of files was available to anyone.  The other file had permission controls
applied even before any data could be seen. This file required a second login to
insure that someone other then the person logged in to the computer wasn't
trying to access the restricted file.

Richard Kreiss
GCC Consulting