loosing memory

[Robert Brenstein]

I agree. However, you must have missed my comment in parenthesis -- 
full log is written to a file. The field is basically a console 
window showing only the most recent activity, allowing me to observe 
what the service is doing at any given time.

Rober


>Robert,
>
>From personal and professional experience you should always keep the logs
>not in a
>stack but in a separate log text file. This saves your log if the stack gets
>corrupted and
>prevents the stack from corruption if the logs get too big...
>
>From your stack, you should read or parse the file very easily.
>This will save you countless hours if you need to convert your stack to an
>application
>in which case the logs will no longuer be saved in the application...
>
>Last tip: keep your logs together in the same place... saves lots of folder
>travel and configs changes!
>
>
>
>>  -----Original Message-----
>>  From: Robert Brenstein [mailto:rjb at rz.uni-potsdam.de]
>>  Sent: 15 January 2003 15:50
>>  To: metacard at lists.runrev.com
>>  Subject: loosing memory
>>
>>
>>  I have a field in which I keep log of activities. The number of lines
>>  is fixed -- as a new line is added on top, a line is deleted on the
>>  bottom. In essence:
>>
>>  delete last line of fld "log"
>>  put txt & return before fld "log"
>>
>>  MC 2.4.3 keeps adding* 0.4-0.5 mb of ram for each such a log entry,
>>  eventually using up all free memory and crashing the server. To make
>>  things confusing, when I take the same function and run it in a test
>>  stack, the same memory loss is not occuring.
>>
>>  The function does a few other things (like appending the log entry to
>>  the file), but commenting out the lines that write to the visible
>>  field eliminates the memory loss (commenting out the file writing
>>  code makes no change).
>>
>>  Anyone has any ideas what might be going on?
>>
>>  Robert Brenstein
>>
>>  *) This is under Mac OS Classic, so "adding" means that the total
>>  memory partition allocated to MC keeps increasing at th expense of
>>  free memory.
>>  _______________________________________________
>>  metacard mailing list
>>  metacard at lists.runrev.com
>>  http://lists.runrev.com/mailman/listinfo/metacard
>>
>
>
>Visit us at http://www.clearstream.com
>                                                          
>IMPORTANT MESSAGE
>
>Internet communications are not secure and therefore Clearstream 
>International does not accept legal responsibility for the contents 
>of this message.
>
>The information contained in this e-mail is confidential and may be 
>legally privileged. It is intended solely for the addressee. If you 
>are not the intended recipient, any disclosure, copying, 
>distribution or any action taken or omitted to be taken in reliance 
>on it, is prohibited and may be unlawful. Any views expressed in 
>this e-mail are those of the individual sender, except where the 
>sender specifically states them to be the views of Clearstream 
>International or of any of its affiliates or subsidiaries.
>
>END OF DISCLAIMER
>_______________________________________________
>metacard mailing list
>metacard at lists.runrev.com
>http://lists.runrev.com/mailman/listinfo/metacard