Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!tut.cis.ohio-state.edu!ucbvax!ucsd!nosc!humu!pegasus!tleylan From: tleylan@pegasus.com (Tom Leylan) Newsgroups: comp.databases Subject: Re: Clipper: Okay, now I'm really pissed Keywords: arrays SAVE Message-ID: <1991Apr28.230635.9117@pegasus.com> Date: 28 Apr 91 23:06:35 GMT References: <1991Apr27.210921.9751@anomaly.sbs.com> <27535@hydra.gatech.EDU> Organization: Pegasus, Honolulu Lines: 42 In article <27535@hydra.gatech.EDU> jgb@prism.gatech.EDU (James G. Baker) writes: >In article <1991Apr27.210921.9751@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: >>BUT YOU STILL CAN "SAVE TO" THE F**KING THINGS! >> >>What good is an array if you can't SAVE it in a MEM file and recall it at >>a later time? What good is setting up that array of user-customized default >>program operation flags if you can't SAVE them? > >Sorry you're so upset. Although there *are* libraries out there for a >few cents that will allow you to save arrays, you could write a function >that would save an array's contents to a disk file or database. James, You're right that if anybody wanted to do it they could simply write the code... it is a language after all not an end user product. To Michael may I suggest you stop using .MEM files. They are kludge and support for them will diminish over time. And before anyone screams at me to defend the "kludge" remark... 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. They don't obey scoping rules... variables created in one place mysteriously appear in another. You don't see a declaration in the code you see RESTORE FROM and whatever happens to be there is pulled into RAM. They can modify existing variables without warning which makes "black-box" routines difficult as the variable name is directly related to the thing operating successfully. Personally I think dBASE suffers major flaws as a computer language and the improvements offered in Clipper 5.0 are a welcome move to bring much of it into line with other languages. The changes will not be welcomed by all one of dBASE's claims to fame is that just about anybody can get something that will operate using EDIT mode. Some will see it as a bother, some will see it as impossible and a few will see it for what it is, an opportunity to improve our applications, make them more robust, make our functions more reusable. If anybody is attending the Clipper Developer's Conference in Palm Desert this June, I'm presenting a workshop titled "Evolving S'87 Code to 5.0" you might want to sit in and find out "why" things are done. tom leylan (ex-Senior Systems Analyst / Nantucket Corporation )