Out of Memory Error & 64K memory limit 
Author Message
 Out of Memory Error & 64K memory limit

I have written a large school administration application in Access 97. It
uses the split database design, and the front-end of my application (with
virtually no local table data) is about 16 MB when compacted.

One of my schools that has a roughly 120 MB back-end database with their
database is getting the "Out of Memory" message about once a day while
using my application, and I cannot figure out what to do about it. Whenever
they get the error, they Exit from Access, go back into the application,
and they redo whatever failed and it works. I also occasionally get this
error while doing development, but not as often as they do. They use Win NT
workstation computers with 32 MB RAM, and I use a Win 95b computer with 32
MB RAM.

I have already talked to MS Access support and gotten configuration tips
for their Win NT computers. I will try their suggestions in a few days when
I get the opportunity. For now I want to learn more about how the 64K of
memory is managed so that I can streamline my application to not run into
this limit.

I have already done the following things to my database to fix memory
problems:

* I explicitly close all recordsets and databases and set them = Nothing
immediately after closing them.

* My application has no global variables. There are less than 10 static
variables in the entire app, and none of them are arrays or large strings
or fixed length strings.

* I have grouped public procedures into standard modules so that related
procedures are in the same module. Also, I use module level variable
declarations only when absolutely needed.

* Also, I have several large blocks of code (hundreds of lines each) that
can either be standard modules or code behind a form. I recently attached
this code to forms in the hope of solving memory problems have having that
using memory on when the form is open.

Here are my questions:

* As an Access application grows (mine is three years in the making) and
has an increasing amount of code in standard modules and attached to forms,
does all of this additional code itself somehow use up the 64K limit or in
some other way make a database more succeptible to getting the "Out of
Memory" message? When asking this question I am assuming that all of the
code uses dynamic local variables. Note: I have never gotten a "Procedure
too large" error, but I have been getting "Out of Memory" errors with
increasing frequency in recent months.

* Is there anything besides recordset and database variables that needs to
be closed and set to Nothing in order to release memory while an
application is running?

* One of my standard modules has a few dymanic arrays that I expand with
ReDim Preserve as needed while the code is running. These arrays are
declared at the module level not the procedure level. When the last
procedure finishes running, are those module level arrays cleared from the
64K?

* Is there any way to diagnose what is consuming memory when the "Out of
Memory" message occurs? It sure would be nice to be able to know for sure
whether the 64K limit has been reached and why. As things stand now, there
is no way for me to know whether my "memory" problem is a programming
problem related to the 64K limit or whether it's a swap file configuration
problem in the OS.

* Do static variables ever get released from the 64K once they have been
declared, or do they hang around in the 64K memory until you close the
application.

Sorry this is a long one, but this has not been an easy problem to deal
with!

Monk.



Sun, 11 Feb 2001 03:00:00 GMT  
 Out of Memory Error & 64K memory limit
I don't think you're running into a memory limit per se.  I have had similar
problems and they are usually related to heavy database and object creation
activity.  Access doesn't garbage collect while it's running - nor does it
allow the OS to expand it's swap file fast enough.  Try putting in

dbengine.idle dbcacherefresh

before starting major database updates.  Don't know if this will work for
you, but it does force Access to run internal maintenance routines.
Additional comments throughout your message.

Also, where did the 64K limit come from?  Access 97 is a 32 bit application
and can potentially use 512 Mb address space on Win95 and 2Gb address space
on NT4.

Mike Ober.



Quote:
>I have written a large school administration application in Access 97. It
>uses the split database design, and the front-end of my application (with
>virtually no local table data) is about 16 MB when compacted.

>One of my schools that has a roughly 120 MB back-end database with their
>database is getting the "Out of Memory" message about once a day while
>using my application, and I cannot figure out what to do about it. Whenever
>they get the error, they Exit from Access, go back into the application,
>and they redo whatever failed and it works. I also occasionally get this
>error while doing development, but not as often as they do. They use Win NT
>workstation computers with 32 MB RAM, and I use a Win 95b computer with 32
>MB RAM.

>* As an Access application grows (mine is three years in the making) and
>has an increasing amount of code in standard modules and attached to forms,
>does all of this additional code itself somehow use up the 64K limit or in
>some other way make a database more succeptible to getting the "Out of
>Memory" message? When asking this question I am assuming that all of the
>code uses dynamic local variables. Note: I have never gotten a "Procedure
>too large" error, but I have been getting "Out of Memory" errors with
>increasing frequency in recent months.

Try the /Decompile switch on the application.  This will free the space used
by all the compiled code, including code that no longer runs.  After
decompiling, open a module and select "Debug.Compile and Save All" before
compacting the database.

Quote:

>* Is there anything besides recordset and database variables that needs to
>be closed and set to Nothing in order to release memory while an
>application is running?

Nope

Quote:

>* One of my standard modules has a few dymanic arrays that I expand with
>ReDim Preserve as needed while the code is running. These arrays are
>declared at the module level not the procedure level. When the last
>procedure finishes running, are those module level arrays cleared from the
>64K?

You probably will want to explicitely release these arrays.

Quote:

>* Is there any way to diagnose what is consuming memory when the "Out of
>Memory" message occurs? It sure would be nice to be able to know for sure
>whether the 64K limit has been reached and why. As things stand now, there
>is no way for me to know whether my "memory" problem is a programming
>problem related to the 64K limit or whether it's a swap file configuration
>problem in the OS.

>* Do static variables ever get released from the 64K once they have been
>declared, or do they hang around in the 64K memory until you close the
>application.

Static variables are just that - static.  They (and constants) get created
at application startup and destroyed at application exit.

Quote:

>Sorry this is a long one, but this has not been an easy problem to deal
>with!

That's OK.

- Show quoted text -

Quote:

>Monk.



Mon, 12 Feb 2001 03:00:00 GMT  
 Out of Memory Error & 64K memory limit
Monk:

Here's a couple of answers for you:

1.)  The 64 K limit was an Access 2 thing, Access 97 has no such limit.
2.)  There are  a number of things which can make a db succeptable to out of
memory errors other than closing recordsets etc.  You may have a few
lurking:

Arrays declared at the module level aren't cleared until you clear them  You
do this by eiter using the Erase command or ReDim MyArray(0).  If this is a
hugh array it could impact your problem, but not likely as Access would just
swap this out to disk.  One way to get around this is if you can put all the
code which access the array(s) into a class.  Then you can use the class'
terminate procedure to clear the array.

Static Variables are just that, static.  They don't go away.....

The bigger issues most of the time are the number of recordsets open at any
given time  (i.e. queries on combo boxes on forms + queries for previewed
reports + recordsets in code etc. etc.   Look at your app and forms
regarding this issue.

If you have a hugh number of controls on a form, especially if it includes
memos or OLE fields will also suck resources.  Its not so much one form will
do it, its when you add all the other stuff.

If you use any of the domain function (dlookup, dcount, dsum etc.)  These
essentially open recordsets too.  Access97 isn't too good at releasing the
memory for these it appears so stay away from them.

Lastly, check your disk space for swap files (read virtual memory).  Access
likes to swap a good deal, even in a 32 mb environment (On NT 32 mb can be
chewed up in a heart beat, heck on one of our workstations, simply booting
the thing will consume up to 55-60 mb of ram (a number of background stuff
is running like winfax etc.))  If you don't have enough swap file space
available, and NT, although it will dynamically size the swap file likes 'em
large.  You can get out of memory errors if Access doesn't have enough swap
file space.

HTH

Steve Arbaugh
ATTAC Consulting Group
web: http://ourworld.compuserve.com/homepages/attac-cg/acgsoft.htm
To reply, remove ~ and nospm from address



Quote:
>[My users] keep getting the "Out of Memory" message about once a day while
>using my application, and I cannot figure out what to do about it. Whenever
>they get the error, they Exit from Access, go back into the application,
>and they redo whatever failed and it works.
>I have already done the following things to my database to fix memory
>problems:

>* I explicitly close all recordsets and databases and set them = Nothing
>immediately after closing them.

>* My application has no global variables. There are less than 10 static
>variables in the entire app, and none of them are arrays or large strings
>or fixed length strings.

>* I have grouped public procedures into standard modules so that related
>procedures are in the same module. Also, I use module level variable
>declarations only when absolutely needed.

>* Also, I have several large blocks of code (hundreds of lines each) that
>can either be standard modules or code behind a form. I recently attached
>this code to forms in the hope of solving memory problems have having that
>using memory on when the form is open.

>Here are my questions:

>* As an Access application grows
>does all of this additional code itself
>somehow use up the 64K limit or in
>some other way make a database more succeptible to getting the "Out of
>Memory" message?
>* Is there anything besides recordset and database variables that needs to
>be closed and set to Nothing in order to release memory while an
>application is running?

>* One of my standard modules has a few dymanic arrays that I expand with
>ReDim Preserve as needed while the code is running. These arrays are
>declared at the module level not the procedure level. When the last
>procedure finishes running, are those module level arrays cleared from the
>64K?

>* Do static variables ever get released from the 64K once they have been
>declared, or do they hang around in the 64K memory until you close the
>application.

>Sorry this is a long one, but this has not been an easy problem to deal
>with!

>Monk.



Tue, 13 Feb 2001 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. PB 64k limit & output limit

2. Out of Memory Error - 64K Segment

3. Q: 64k memory limit? Other memory Q's...

4. Memory, Memory and more Memory

5. memory (out of memory error)

6. memory 64k

7. memory > 64k

8. Out of memory error & database bloat

9. Out of memory errors & NT

10. Active X Documents & Out of Memory error

11. Text Box Memory Limit?

12. Text box Memory Limit?

 

 
Powered by phpBB® Forum Software