erbo@mango.ucsb.edu (Eric J. Bowersox) (09/01/89)
I am (still) writing a large application under dBASE IV at work, designed to handle the tracking of expenses. Just this evening, as I was entering test data into the recently-coded system for the generation, printing, and reporting of purchase orders, I got the infamous "Insufficient memory" error. (What's nasty about that is that even my program's error handlers wouldn't function; dBASE had to handle all the work itself.) Now, as I was in the process of halting both my program and dBASE, I thought of a possible problem: Since my application shuttles a lot of string data between the databases and memory variables, perhaps old copies of this string data were being kept around in memory, as in some versions of BASIC. What I mean by this is, if you executed the following two state- ments: str_var = "CAT" str_var = "DOG" that the string "CAT" would not _really_ be eliminated from memory, but kept hanging around someplace, even though no other character variable actually referenced it. Now, what I want to know is: 1) How accurate am I? Does dBASE really do it this way? Or is it just my program's fault that it uses so much memory? (I know it would be _REAL_ easy to assume the latter, but that would mean I'd have to redo a lot of this module, which is most definitely NOT what my supervisors want to hear right now ... :-) ... and besides, it'll only get worse in the future.) 2) If, by some miracle, I _am_ correct, is there any way of reclaiming or "garbage-collecting" that unused space, that my program could use periodically so it doesn't run out of room? (Those versions of BASIC I mentioned earlier would do it if you asked for how much memory was left, sometimes...would calling MEMORY(0) do the same thing under dBASE IV? If so, it wasn't in the manual.) Sorry if this is a bit long-winded, but I'm really up to my keister in this project, and I just have to find some sort of answer, even if the answer means I'm SOL, as it were. Perhaps Alastair, who gave me such a thorough answer before, would condescend to reply :-). Please reply by e-mail, or post if you think it's of general enough int- erest, and, as always, send all your flames to /dev/null. Thanks! | Disclaimer: "Disclaimer?! I don't even KNOW her!!" -- M. Coohill | | * Eric J. Bowersox (ERBO) * LIVE! from Isla Vista, California! | | erbo@cornu.ucsb.edu ...!{ucbvax,ucsd}!ucsbcsl!cornu!erbo | | Brain fried error reading drive C -- Abort, Retry, Ignore, Fail? |
mr@cica.cica.indiana.edu (Michael Regoli) (09/02/89)
erbo@mango.ucsb.edu (Eric J. Bowersox) writes: >I got the infamous "Insufficient memory" error. eric, welcome to dbaseIV! > is there any way of reclaiming or "garbage-collecting" that > unused space . . . you could use the "RELEASE" command to discard those uneeded memory variables. ("release all like mem_*" would dust them). you should also increase your "bucket" size by including a statement in your config.db file: bucket = 10 one bucket is 1K of memory. the above statement increases memory allocation by 10K. the limit is 31K. hope some of this helps... -- michael regoli mr@cica.indiana.edu regoli@iubacs.bitnet ...rutgers!iuvax!cica!mr
mraustad@infocenter.UUCP (Mike Raustad) (09/08/89)
In article <141@cica.cica.indiana.edu>, mr@cica.cica.indiana.edu (Michael Regoli) writes: > > you could use the "RELEASE" command to discard those uneeded > memory variables. ("release all like mem_*" would dust them). > bucket = 10 These are two very important pieces, but it is also vital that you are able to MANAGE your memory variables and space. Releasing variables is good if you do not require the use of them again. In addition to the above commands, I recommend placing the DISPLAY MEMORY command in your program somewhere before your program bombs. This command is very useful for managing memory. Review the output and rid your memory of the variables you do not require. If you require the variable later, use the SAVE and RESTORE commands, otherwise RELEASE will do the trick. Once you have the variables under control, remove the DISPLAY MEMORY line from your program. ___________________________________________________________________________ / MIKE RAUSTAD __ ENCORE COMPUTER CORP. / 6901 W. Sunrise Blvd. / /\/\ o / __ /__) __ __/ __ ___/ Ft. Lauderdale, Fl. 33313 / / / / / /) (__ / \ /_/ / / /\ / /_/ / / PHONE: (305)-797-5621 / / /_/_/ \_(__ / /_/ /_(__/_/__)_/_/ /_(__/ EMAIL: uunet!gould!mraustad /