Running out of memory.

Fuga

Registered User.
Local time
Today, 03:31
Joined
Feb 28, 2002
Messages
566
Every 5 minutes my db goes to the net, copies a few pages, pastes in word and imports it to access or excel and then it all ends up in either a text file or a table in the db.

In word, typically, there are som find/replace operations.

In excel, also some replacing and filling.

In access, an automatic docmd.transfertext operation, followed by an append query.

all instances of Iexplorer, msword and msexcel are quitting like they are supposed to (except for the instances I might be using simultaneously).

Yet I run out of memory

After about half a day I have to reboot:mad:

Has anyone had a similar problem? Is there a vb command I can use to "emty the memory"?

After recieving the "out of memory" errormessage, I get the "access has performed a forbidden action(trans from swedish)" errormessage. This msgbox just keeps popping up.

Lovely!

Fuga.
 
Ok, checked it out.

But there must be something you can do, isn´t there?

Fuga.
 
Hey, I just thought of something.

If I have a window of Iexplorer open all the time, does this mean not only this window but all windows of Iexplorer during the entire day will stay resident in the memory until I quit the application??

Fuga.
 
Here is the reason and some solutions for the problem:

ACCESS ONLINE ENCYCLOPEDIA www.unsoftwareag.com Article Code: G3

Why insufficient memory ?
Description


You can have installed lots of RAM (128 MB and more) on your machine but nethertheless ACCESS crashed after a short period of time indicating that you do not have enough memory to display something. This problem is very frequent during the development phase as you often have to change into design view of forms, reports and modules.
In general you need to reboot your computer to be able to continue. Upgrading your RAM to 256 MB (and more) does not help.
If you check the "Free ressources" window (Windows System or ACCESS Information window) you see between 5 % and 50 % .
Sometimes you will see a system alert with "Memory Running Low" before the crash.
This crash happens on different computers at different times: On Computer 1 ACCESS will crash as soon as the ressources drop under 50%, whereas Computer B will work with less than 10%.

Explanation Part 1


The RAM is divided in different areas that hold different system information. In the so-called GDI-HEAP information about the open windows are stored (Position, Status, Size, Handle...) The size of the GDI-HEAP is limited to 64kB - independantly from the total RAM installed on your machine. Once the GDI-HEAP is saturated the system (or certain programs) will crash.

Explanation Part 2

As soon as you close a window, the occupied area in the GDI-HEAP should be released. Unfortunately, this does not work properly with ACCESS neither on closing a single database object (Form, Report, Module...) nor on closing ACCESS.
Explanation Part 3


As soon as you ope any VBA module (globales or Form/Report class module) all modules of the application are opened, each in a single window. In any medium sized application it can easily happen that 100 windows are opened instantly. This moment leads quite often to a crash because the GDI HEAP is saturated.
Solutions

There are several workarounds, you should opt for a combination:
Limit the number of forms, reports and modules.
Delete all unused database objects
Limit the number of background graphics and tab controls
Distribute your database objects on different libraries
Recreate your database file regularly and import the objects
Activate the VB password and only one module window will be opened at a time
(ATTENTION: removing the VB password again might become difficult).
Do not close forms that you permanently need but make them invisible. See Article F46 for details.
 
Another thing you can hope to do, but this might not be enough.

1. Remember to CLOSE everything you open when it isn't in use.

If you open a recordset, always close it. If you open a database through a database variable, always close it. If you open an application object, always close it. If you open a file in VBA, always close it when done.

BUT - if you are going to rescan a recordset several times, consider leaving it open in a global module context, then just do a .MoveFirst to rescan it. ONLY if you are careful to record the state of the recordset in your code and to check whether it is open before opening it.

2. Remember to avoid intermediates that you don't need to use when a default or shortcut already exists that you can use.

If you use this construct:

Dim myDB as DAO.Database
Dim myRS as DAO.Recordset

Set myDB = CurrentDB
Set myRS = myDB.OpenRecordset...


Consider using

Dim myRS as DAO.Recordset

Set myRS = CurrentDB.OpenRecordset...

Instead of opening the current form, use Me as the shorthand. When using Word or Excel automation, use the ActiveDocument and ActiveSheet shortcuts.

There are other options you could use, too. But this gives you an idea of some things to cut down on "Open" actions.

None of which should be taken as contradicting the advice offered by ElsVanMiert.
 
Ok thanks you guys!

I´ve thought about what you have been saying. First of all, I´m going to assume that it is really access that is the problem, and not one of the other applications.

I use a series of forms, splitting the code up in sequences in order to get a pause in the code (on timer event on each form). The reason is of course that otherwize the commands are not processed in the right order. There are about 12 forms (at most, four of them are open at the same time).

Now if I understand it correctly, this is the kind of thing that can fill up a memory, even if I think access should be able to handle it.

If I´m right, I need a code example of how to halt code for a few seconds. I´ve looked up doevents, but I don´t know how to use it or even if this is really what I want.

I use A97.

Fuga.
 

Users who are viewing this thread

Back
Top Bottom