thanks David.  I like to be stingy with writing code, maybe
ultra-economical.  Seems to me that I use and reuse about 100 variables
constantly, and that setting them to null instead of clearing and resetting
them seems pretty efficient.  If I don't hear any objections, I'll keep
doing it until I get smacked down.

bill

On Wed, Apr 20, 2011 at 11:42 AM, Fitts, David A.
<[email protected]>wrote:

>  Greetings,
>
> In the past year and a half I migrated about 20 years worth command
> files (100+) from our old Rbase version 2.11 database to version 9.1 (64).
>
> My oldest command files were pretty bad examples of coding, most of them
> didn't even clear variables before running and many of them relied on other
> command files to set up variables for use in the fashion I think you are
> describing in your email.
>
> In converting my old command files of course I had to get rid of reserved
> words that Rbase 2.11 had allowed and 9.1 didn't allow. I also had to change
> a few commands like CONNECT for OPEN and SET POINTER with FETCH commands.
> Aside from these changes, the commands created using 2.11 are all working
> well in version 9.1 and it doesn't seem to matter whether they clear
> variables before running or let the variables sit in memory for later use.
>
> Based on my experience so far, I think you can continue to do what you are
> doing without any trouble in 9.1 but I would certainly defer to Razzak's or
> any one else's  recommendations.
>
> Regards,
>
> David Fitts
> State of Maine
> Risk Management Division
> 287-3352
> 1-800-525-1252
>
>
>  ------------------------------
> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *William
> Stacy
> *Sent:* Saturday, April 16, 2011 12:40 PM
> *To:* RBASE-L Mailing List
> *Subject:* [RBASE-L] - setting variables
>
> Am migrating, ever so slowly, from 4.5++ (dos) to 9.1 (64).  Have a large
> ap that I've used to run my practice for many years, and use about 1000 cmd
> files that use and re-use variables.
>
> I noticed that Razzak and others seem to have developed a careful set var
> and clear var procedures in their cmd files, forms, etc. that seem to "start
> over" with each use of vars.
>
> In earlier years I was aware of some memory leaks or something that would
> over time degrade the performance of rbase, so I made a habit of declaring a
> long list (about 100) of variables that I would use over and over again,
> setting them only in this "setvar" cmd file that is always run right between
> starting rbase and any workstation login file (password control, etc).
>
> This works well, and has enabled me (caused me?) to shorten my syntax to
> the following example:
>
> 1. in the setvar file I have this kind of statement:  set var t1 text='   '
> 2. in the command files I use things like this: t1='Personal health'
> 3. at the end of each command file I have this: t1=null (unless I want to
> keep "personal health" in the .t1 for the next cmd file, in which case I
> just leave it as is.
>
> Thereby, in my cleverness, I have a minimum of coding and my variables
> never get actually "cleared" until the ap actually closes.
>
> So my question is, am I just using sloppy programming, not making it clear
> what is happening at each and every statement, or is this kind of
> programming dangerous or even disallowed in 9.x?  Has the memory leak of old
> been fixed forever, or is it still happening?  And does my system actually
> help plug or eat least slow the (real or imagined) leak?
>
> TIA, and sorry if I asked this same thing  a while back in a clumsier way.
> I am now at the point of major or not so major rewriting of thousands of
> lines of code. I would prefer the not so major, but can be convinced it
> needs to be major. I am aware that with the placing of code within forms
> themselves, many of my beloved cmd files may become obsolete anyway.
>
> Bill
>
> --
> William Stacy, O.D.
>
> Please visit my website by clicking on :
>
> http://www.folsomeye.net
>
>
>
>


-- 
William Stacy, O.D.

Please visit my website by clicking on :

http://www.folsomeye.net

Reply via email to