Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!uunet!mcsun!cernvax!chx400!forty2!eichi From: eichi@forty2.physik.unizh.ch (Stefan Eichenberger) Newsgroups: comp.databases Subject: Re: Clipper: Okay, now I'm really pissed Keywords: arrays SAVE Message-ID: <1570@forty2.physik.unizh.ch> Date: 29 Apr 91 14:34:09 GMT Article-I.D.: forty2.1570 References: <1991Apr27.210921.9751@anomaly.sbs.com> <27535@hydra.gatech.EDU> <1991Apr28.230635.9117@pegasus.com> Organization: Physics Institute, University of Zuerich, Switzerland Lines: 38 >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. Well, I give you two examples I use .MEM files for, which would be awfully complicated and overkill to find other solutions for: - Configuration file: Each user can modify his/her own config.mem file, which contains some - in my app. roughly 50 different - parameters, all of different type, length, etc. Each user has its own file in a local directory, the network remark above doesn't hold, therefore. - For security reasons, I've to store a couple of *.dbf files on diskettes only and copy them to harddisk only for the duration of a session, deleting and wipeing them afterwards. Each diskette now also contains a .MEM file, with which I do automatic version control - what if the program gets updated and an old disk still floats around somewhere, and that sort of thing. Of course, both could be done with an abuse of .DBF files, but much more elegant are .MEM files. Scoping rules are implemented by the variable names: c* come from the config.mem, whereever they appear in the application, etc. It's in any case difficult to implement local variables in Clipper apps. (I haven't swiched to version 5 yet, are there improvements?), and binary files - e.g. all other files apart from .DBF and .NTX, things created with fwrite(), fread() don't document file locking mechanisms in Clipper '87! -- ---------------------------------------------------------------------------- iNet: eichi@physik.unizh.ch Stefan Eichenberger UUCP: ...mcsun!chx400!forty2!eichi Physics Institut BITNET: K807817@CZHRZU1A University of Zurich