Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!raybed2!rayssd!anomaly!mpd
From: mpd@anomaly.sbs.com (Michael P. Deignan)
Newsgroups: comp.databases
Subject: Re: Clipper: Okay, now I'm really pissed
Keywords: arrays SAVE
Message-ID: <1991Apr29.112508.23017@anomaly.sbs.com>
Date: 29 Apr 91 11:25:08 GMT
References: <1991Apr27.210921.9751@anomaly.sbs.com> <27535@hydra.gatech.EDU> <1991Apr28.230635.9117@pegasus.com>
Organization: Small Business Systems, Inc., Esmond, RI  02917
Lines: 32

tleylan@pegasus.com (Tom Leylan) writes:

>I have a dozen reasons but primary among
>them are that in multi-user apps there isn't any locking mechanism so one
>workstation can change the values behind another station's back.


However, they are immensely helpful for maintaining an individual's personal
configuration on disk. For example, if I set a series of variables, the 'v*'
variables, to "default" values at the beginning of the program, then a user
who does have their own "profile" saved is logging in, a "RESTORE FROM" can
restore their PERSONAL defaults from their previous session. 

This has little or no effect on other users. Although it may break your idea
of "scoping laws", it still, however, is much better than sitting around with
a single configuration file open all the time to constantly read and modify
someone's default configuration.

Not to mention the dynamic allocation of tables, which are built at run-time
and need to be saved for later recall. This, however, is a completely
different story.

The plain fact is that Nantucket's oversight once again to give people the
ability to save arrays is downright inexcusable - especially in light of all
the other nice array handling functions they did include.

MD
-- 
--  Michael P. Deignan                      / Since I *OWN* SBS.COM,
--  Domain: mpd@anomaly.sbs.com            /  These Opinions Generally
--    UUCP: ...!uunet!rayssd!anomaly!mpd  /   Represent The Opinions Of
-- Telebit: +1 401 455 0347              /    My Company...