I am curious if the browser control is the issue, would closing the form
with control free up memory? So perhaps the code rather then refresh the
form, would close and re open the form?
and just to clarify Larry, using your example you are right but my emphasis
was a shared app on a windows network (this is very apparent with more then
one user connected and at least one user is entering data) the memory usage
will continue to rise as you work and not drop much no matter what you do.
If anyone is interested you can get the same results using RRBYW14. Now
granted, maxing out RAM has not been an issue however I have multiple users
RDP into a server to use an app all day long, once they start hitting
150,000+ k by the afternoon, they MAY experience what we call 'weirdness'
which means, temp data doesn't get loaded or updated, forms/reports don't
load completely, or the I/O and lock up issues. They will sign out, sign in
and return to what they were doing and it will work fine.
I would love any suggestions on how to clear allocated memory because
clearing variables, disconnecting/reconnecting, and deleting scratch files
doesn't do it and honestly I don't know if it is possible since I think this
is a MS file sharing thing.
----- Original Message -----
From: "Lawrence Lustig" <[email protected]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Tuesday, February 16, 2010 1:29 PM
Subject: [RBASE-L] - Re: Memory Usage out of hand
<<
As it's used, memory use will grow all day long, and no matter what is
done, it will not clear till the app is closed. You (and infact everyone)
should see this behavior with other shared apps on a windows network,
although you won't reach a 'tapped out' state for most, you will see the
memory use will grow and grow as people use it but it will never go down
no matter what
This is not correct. A well-written program will allocate and deallocate
memory as needed, and you will see its memory usage go up and down as you
use it.
To see this happening in R:Base, start R:Base and open the task manager.
Look at the memory R:Base is using. Now, RBEDIT a really large text file
(multiple megabytes). You'll see R:Base's memory usage shoot up as it
loads and processes the file. When the file is fully loaded, R:Base will
release some of the memory it used during the load process, but will still
be using a good deal more memory than it was originally (naturally,
because it has that large file open). Now, close RBEDIT and you'll see
R:Base's program usage drop back to approximately what it was when you
started it.
R:Base is allocating and deallocating memory as needed.
Unfortunately, many programs do leak small amounts of memory so that, as
their memory usage goes up and down during the course of a session, it's
on a somewhat upwards trajectory. When that happens in a process linked
to your application (in this case, perhaps, the Internet Explorer browser
control) then your application will appear to be the one using the memory
and there isn't much you can do about it.
--
Larry
--- RBASE-L
================================================
TO POST A MESSAGE TO ALL MEMBERS:
Send a plain text email to [email protected]
(Don't use any of these words as your Subject:
INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH,
REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP)
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: INTRO
================================================
TO UNSUBSCRIBE:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: UNSUBSCRIBE
================================================
TO SEARCH ARCHIVES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: SEARCH-n
(where n is the number of days). In the message body,
place any
text to search for.
================================================
