Out of memory, can't update display

Hello Experts,

My application just started giving me the following error:


“There isn’t enough free memory to update the display. Close unneeded programs and try again.”

This just started when I created three Pop-UP/Modal Forms that I use to prompt for user input.  These forms contain command buttons which are evaluated after the selections are made and the form is closed.  The values selected are then loaded into Public Variables.

What might I be doing that is hogging up all my memory ? I have rebooted and loaded only my application, no email, schedule, or anything else is running that I know of.


PC: Dell 350Mhz, 128M Ram

OS: Windows95, win is managing virtual memory

App: Access97.mdb file (local front-end, back-end on server).  All database objects are closed and set = nothing.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

check that installation of SP1 and SP2 of Office '97 was successful.

this symptom has been suggested to be connected with which version of service pack is installed.

Believe it or not, we had a machine generating this error because of an incompatibility with a video driver.  I would go with ssam's suggestion, but you also might want to try it on a differently-configured machine just to make sure hardware isn't an issue.

believerAuthor Commented:

Yes, I am up to SR-2. I should have included that in my specifications.


I've been using/developing this application on this machine for over a year.

The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

Our suspect machine only started failing on us after we added a few controls to a form.  The app works fine on other machines with different hardware but with an identical build of Access.  Just a thought.

believerAuthor Commented:

Thanks, I'll keep that in mind.

When I run the windows system monitor, and choose all the memory selections, the only one that act peculiar is “Other Memory”.  It goes to about 70M and stays there. All the others, and the processor appear to react when the app is busy, and then go back down when the app is idle.

I don’t know what all “Other Memory” is being monitored, but maybe this includes video memory?
All windows does to explain it is to say: Number of bytes of memory allocated which are not stored in the swap file. Examples of ‘other’ memory are disk cache pages, memory allocated fixed (non-pageable), and memory-mapped files.

Still investigating…
I too have this problem with the same general setup.

I have tried everything I can think of!

I'm using NT 4.0, and so I have the ability to monitor memory usage on the fly.  I deliberately triggerd this error, and the memory usage did not change 1 byte.

MS's knowledge base says that if in Access '95 you have subforms with navigation buttons this will happen, and that the workaround is to remove the nav buttons and create your own custom buttons.  They say that this is a known bug that was fixed for v'97.

I'm using 97, and the subforms that were up when I get the error have no nav buttons.

They also said that having a startup form specified inthe start options can cause this, and so opening forms should be put into an autoexec instead.  But that didn't help my problem.

I had not considered that it might be the modality of the form.

I can tell you for sure, the error takes place the instant control is released from the Popups module that closes the popup.

I'm listening attentively to what transpires in this thread!
more fuel to the fire, so to speak:  we have a similar problem where the forms run fine, but we get the out of memory error after printing a number of reports (20+).  thus, we've been looking into the SP's, but it hasn't been fruitful.  does anyone know of any kernal bleeds in win98 or win95 (ver B) or patches thereof?  

also, wesleystewart's comment about working fine on other machines holds true in this case too.  
My particular problem, (the popup, modal), does the same thing on every machine I've tried it on, (laptops, intels, cyrix's).

We just now tried making the popup not popup, not modal, and the problem ceased!

Now I'm pursueing a work-around, and I'll let you know what happens.

Plus, re: " . . . any kernal bleeds in win98 or win95 (ver B) or patches thereof?", our memory usage did not change AT ALL!  (Shouting because of the frustration at having a memory error while there's lot's of memory.)

Let me ask a dumb question.  Have you done any or all of these fixes?

Repair and Compact

Run JetComp.EXE

Created a new blank database and imported all the objects from this DB

Guess that is not important as you seem to indicate that it works fine on other machines.  Is that true?

What have you added to the machine in the way of software or hardware recently - between the time that it worked perfectly and the time is started failing?

We had a similar problem a while back and we finally discovered that it was an updated driver for a HP printer.  When we went back to a more generic driver, ie lower version, the problem went away.  This has been verified on this topic a couple of times in the past five months also.

Did you add any new activeX or third party controls to the application lately?

A lot of time you will have a conflict between drivers, which don't seem to be involved with the app, or conflict with libraries and Windows doesn't really know what the error is.  So the generic errors which pop up other than GPF, which is a variation of memory - Win wrote to a page in memory but when it went back, the checksum didn't match - ergo Page Fault Error, are usually assumptions that since something has been lost or where Win wanted to write a block, Windows finds a video block.  Hey!  This most be a 'not enough memory' error because video blocks are always at the top of memory.  To reach that, I'm out of memory - duh!

Do you set all your objects to nothing after you are through with them?  It could also be something as simple as too many buffers have been taken to store changes and the garbage has been taken out lately.

You might also try to DECOMPILE the app to see if this cleans up some things.  Remember, every code change you make, every movement of a screen object, renaming an object, deleting, and even changes in data on a form are keep my Access as part of the app.  They don't go away until you repair and compact the app.  Sometimes the code, which also has multiple copies as well as the tokens after compiling can move things into memory where they conflict.

The DECOMPILE switch is not documented.  Run Access from the start box with /Decompile.  Hold down the shift key if the app has an autoexec routine or auto file open until EVERY THING is done.

Then close and open normally.  First thing is recompile the DB.  I've found that copying a form with an ActiveX control can cause problems which didn't show up until I decompile and re-compiled the app.  Then it complained.

After recompiling, close the app and then run repair and compact.

How many stored queries do you have?  Although repair and compact is supposed to recompile the queries also, I like to be save and open each one in design mode, immediately save, and close.  This causes Jet to recompile and optimize the query.

When finished, close app and repair and compact.

The final word, I promise, is if you determine that it is the machine and not the software (it runs on other machines ok), start disabling device drivers you are not using at the moment.  Test after each one is gone.  This may isolate the device driver that may be causing the problem.

Also remove all other software that is running.  Using Ctrl/Alt/Del close all programs but Explorer and SysTray.  Then try running the app again to see if some running software is causing the problem.


I don't see where you got that the problem that started this thread works well on different machines.  When I go back up and read the question, I don't see that, even 'between the lines.'

For myself, I tried everything you mentioned except decompile.  And I think that it is significant that, after reading this question earlier today I tried making the form that causes our out of memory error non-modal, non-popup and the error went away...

Brian: The problem with reading between the lines (or even the lines) is the spacing is too tight!  :-)

I read ssam's comment and thought that I was reading the author's comment.

I guess the question is then does it work on other machines?

Can you send me a copy of that DB which has your error and let me try it on one of my development machines?  I can't imagine what the modal/popup have to do with the error.  I've never seen that fix a memory error.  As a matter of fact since our early, early days of development, we haven't seen a memory error like this.

Surprizingly, we have seen memory errors 3048 & 64509 occur on our test machine which has the most memory in the lab but is basically setup as a graphics machine and is used to write our help files and brochures.  It has the most memory, the best video card, the fastest and biggest monitor, multiple CDROMs and more yet it will get these two failures from time to time whereas my laptop with only 32MB does not.

The only thing that I can think of is Windows in notorious for not really removing programs from memory even when it no longer shows anywhere.  We tested the program with a resource monitor showing and found it did not use up a large quantity of resources.  But when we ran other programs prior to the Access app, we noticed that after they closed, they did not release a large amount of resources.

Sometimes quiting Access doesn't release all the resources.  This is a situation which can occur in a development environment.  You're in and out of Access several times during the day and then WHAM you get a weird error and spend days trying to track it down.

From MS:

ACC2000: "There isn't enough free memory" Error When Working with a Form
ID: Q236977


The information in this article applies to:

Microsoft Access 2000

Novice: Requires knowledge of the user interface on single-user computers.

This article applies to a Microsoft Access database (.mdb) and a Microsoft Access project (.adp).

When you are working with a form and you switch between Design view and Form view, or you print preview a form, you may receive the following error message:

There isn't enough free memory to update the display. Close unneeded programs and try again
However, when you close other programs, including Microsoft Access, no additional memory on your computer is freed.

You may receive this error message if any one of the following conditions is true:

You set the Picture property of the form to a *.gif file.


You created the form with the Form Wizard and selected one of the pre-defined styles.


You used the AutoFormat command to apply one of the pre-defined styles to the form.


You are working in one of the databases created by the Database Wizard that uses forms with styles set.
The pre-defined styles in Access 2000 that use a *.gif file for the Picture property are:
Blue Print
Sumi Painting
NOTE: If you apply these styles to the Picture property of a form, the property sheet erroneously displays '(bitmap)' even though the style actually uses a *.gif file.

After you receive the error message described in the "Symptoms" section, you have to close all applications and restart your computer to free the memory on your computer.

To avoid this behavior, you can either use a different graphic format for the Picture property, or you can remove the *.gif file from the Picture property while you are designing your form, and then add it back when you are finished.

Using a Different Graphic Format
You can use the graphics program of your choice to convert the *.gif file to some other supported graphic format such as *.jpg. After the graphic file is converted, you need to reference the converted file in the Picture property of the form. To do so, follow these steps:
Open the form in Design view and display the property sheet of the form.

On the Format tab, select the Picture property and click the Build button to the right of the text box.

Browse to and select the converted graphic file.

Click OK to set the Picture property to that file.

If you use autoformat styles regularly, you may want to convert them to use a file type other than *.gif. To do so, follow these steps:
Use the graphics program of your choice to convert the autoformat graphic files to a format such as *.jpg. The following files used by the AutoFormat wizard are located in the C:\Program Files\Microsoft Office\Office\Bitmaps\Styles folder in a default installation of Microsoft Office:

Style File Name
Blends acbends.gif
Blue Print acbluprt.gif
Expedition acexpdtn.gif
Industrial acindstr.gif
Ricepaper acricepaper.gif
Sandstone acsndstn.gif
Sumi Painting acsumipt.gif

Reset the Picture property as described earlier in this section.

On the Format menu, click AutoFormat.

In the AutoFormat dialog box, select the style that the form is using and click Customize.

Select Update '<style name>' with values from Form '<form name>'

Click OK twice.

When you apply the built-in style in the future, it will use the converted graphic file as the source for the Picture property.
Removing Picture Property During Form Design
While you design the form, remove the *.gif file from the Picture property. Then after you have finished creating the form and will not be toggling between Design and Form view anymore, you can add the style back to the form. To do so, follow these steps:
Open the Form in Design view.

On the Format menu, click AutoFormat.

In the AutoFormat dialog box, select the format that you want from the Form AutoFormats list.

Click OK.

The picture associated with the autoformat is added back to the form.

Microsoft has confirmed this to be a problem in Microsoft Access 2000.

When you switch a form from Design view to Form view, the picture on the form is converted to a special file type so that it can be displayed correctly. When the Picture property of a form is set to a *.gif file, this conversion process occurs every time that you change the view of the form, and this process uses up memory.

Additional query words: pra

Keywords          : kbdta FmsProb
Version           : WINDOWS:2000
Platform          : WINDOWS
Issue type        : kbbug

Last Reviewed: July 13, 1999

Send feedback to MSDN.Look here for MSDN Online resources.
I've had this problem on a new machine. And it was definitely not related to anything in a form (worked flawless on other machines). As it turned out, updating the printer driver did the trick.
Jim: The app is too complicated to send.  Setup takes 13 1.44M discs.  But as you know, I'm a pretty good debugger, and this has me stumped, (so far).

Carey: I don't need to restart my machine, (as the article states), I only have to close an reopen Access.  leads me to think that it's a differnet problem.

I know this is not my question, so I'm not seeking resolution.  I'm merely hemming in my contribution, in hopes that between us all with our problems, and solutions, and resources this will be a more fruitful thread.

believerAuthor Commented:
Thanks Experts for commenting on this question !

Jim Morgan
I was hoping you would chime in on this one, you usually have some great suggestions…

Let me chronicle my sequence of events:

All database objects are closed and Set = nothing in the code
App is repaired and compressed, then reopened.
Computer is rebooted to clear memory.
No other applications are running.
App opens to a Startup form.
User clicks a command button to go to the reports form (Startup Form is never closed, acts as a switchboard).
User clicks a command button for desired report (Report Form Remains Open)
On open event of report calls a module with approximately 800 lines of code
This module has a Public Host procedure, and about 20 private subs and functions.
First private sub called is “Get Preliminaries”
PopUp/Modal form comes up (first of Three times), to prompt for report criteria
PopUp/Modal form comes up (2nd of Three times), to prompt for report criteria
This is where the error becomes evident:
Text in all command buttons on screen turns white, indicating error about to occur
PopUp/Modal form comes up (3rd of Three times), to prompt for report criteria
Main Report is linked to a table with header only information
Sub Report is a 27x15 matrix of unbound text boxes
The public module fills 4 arrays with calculations from 45 tables some in front end, some in back-end
The final private sub fills the unbound text boxes from the calculated values in the arrays
Entire process takes less than one minute
The report is displayed
The error message pops up

Have Tried:
Acts the same on every machine tested
No new HW or SW has been installed
Created a blank database and imported everything into it, acts the same
No third party or activeX controls are in use in this process, ActiveX control in app is calendar
App has no queries, use only SQL
App has no macros, use only VBA
Deselect PopUp/Modal on form, error still occurs
One other report gets it’s criteria from this same PopUp/Modal form, but it is only call once and problem doesn’t occur

Haven’t Tried
Please tell me more about Buffers, and taking out the garbage ?


As the author of this question, I don’t mind you piggybacking at all.  I welcome your input, as well as your experiences troubleshooting the same problem.

Thanks to All, lets keep it going until this one is laid to rest.
Have you tried stepping through the code, and found that the error happens immediately following exiting the procedure "The final private sub..." you alluded to above?

believerAuthor Commented:

Yes, as soon as the last "End Sub" is
run the error occurs.

I am increasing the points, because I think this is a little more involved than I first thought.

I actually don't think that this is directly solvable.

I'll tell you what it is that I am working on, so that if it works, I can be the first with the 'solution.'

In my OK button, I update a recordset with the value of an unbound text box on the popup.  Then I close 'Me'.

(This popup is:

    Caption:  Equipment Growth
    Prompt:  Set Equipment Growth for this Electronic Space:
    Text box has default value of 15%
    Single OK button.  Click event:

  Private Sub cmdOK_Click()

      On Error GoTo Err_OK_Click
      Forms!frmViewZone!frmDesCompList.Form!ElectGrowth = Me!ElectGrowth
      DoCmd.Close acForm, Me.Name

      Exit Sub

      MsgBox .Description
      Resume Exit_OK_Click
  End Sub

What I'm thinking of doing is changing the click event to:

Private Sub cmdOK_Click()
    gflgCloseEquip = True
End Sub

Then modifying the code that opens the dialog to
gflgCloseEquip = False
Me.TimerInterval = 100
DoCmd.OpenForm "frmSetEquipGrowth" ... acDialog

Then in the Timer Event

Private Sub Form_Timer()

  If Not gflgCloseEquip Then Exit Sub
  Me.TimerInterval = 0

  ' move the code from the dialog close here...
  '  ...
  '  ...

  DoCmd.Close acForm, "frmSetEquipGrowth"

End Sub

The idea is that the form would no longer be running any code when it is closed, and that instead of closing itself, it is closed by a different class module...  I have no idea if this will help me...or you.

Does the plan make sense?

Brian  <X
believerAuthor Commented:
I am trying something similar by closing my report form in my module.

As an additional data point, I tried my app on a machine with Access 2000 and it did the same thing.

I even changed my driver for my HP printer as someone suggested above.


Believer:  Does this occur only when you preview the report?  It doesn't sound like the printer driver but since you are working with a report, my feeling goes back to something in the print routine.

Are the popup forms requesting information for the criteria closed each time?  They aren't stacking up are they?

BTW, we were having problems with the ActiveX calendar control, don't remember now what it was, and so removed it from the app.  Have you tried to either reinstall the calendar control in each of the forms where needed?  If you copy a form with an activeX control to create a new form, sometimes all of the items needed by the control are not set properly.  I always recommend, based on our experiences, to create activeX controls from scratch on a form.

I don't mind taking a look at the DB and using some of my problem solving skills.  If you like, my email address is in my profile.

Carey:  It is interesting to have the MS article reference about the memory error problems.  Kind of like what I said but with more explanation about the backgrounds and pictures.  I guess, unknowingly, that is why I do not use backgrounds in my apps.

Brian:  How well does your app zip down?  I also have a private FTP web site where I can set you up with a password to FTP me a copy.

believerAuthor Commented:

Yes, this only occurs when I preview the report?

Yes, the popup forms requesting information for the criteria are closed each time. Do you know of something additional I can do to remove their existence from any memory, is DoCmd.Close acForm, "frmNPF", acSaveNo good enough ?
This particular report doesn't use the calendar control, so I don't suspect it is the problem.

Thanks for the offer to take a look at my app. I may take you up on that offer. It would take a lot of work to disconnect it from the data and still allow the report to operate.


believerAuthor Commented:
BTW, JimMorgan

Would you elaborate on the earlier comment you made about Buffers ?

"It could also be something as simple as too many buffers have been taken to store changes and the garbage has been taken out lately."


Since we are talking about memory...

Would anyone care to comment on the use of Public variables.

I have a dummy module where I dim many reusable Public variables. There is no code in this module, but it makes it easy for me to find, add, or make changes to these, here is a look at that module. Is this inefficient in any way ?

Option Compare Database
Public strMess$, strTitle$, strDefault$
Public dbs As DAO.Database, strEraseme$, lngYYYYMM&
Public strSQL$, strSqlTrailer$, dblEraseme#
Public strCalDefault$, strCalMess$
Public strCalendarOutput$, dayMMDDYY As Date
Public strFinalMess$, lngEraseme&, lngGFY&
Public tdf As DAO.TableDef, fld As DAO.Field, ThisDb As DAO.Database
Public rst1 As DAO.Recordset, rst2 As DAO.Recordset, I%
Public datStart As Date, datStop As Date
Public strSortBy$, strSortOrder, strProg$

'bolSnapShot is a Public Boolean Variable which determines if
'The 533 is printed or sent to C:\My Documents\XXX.snp
Public bolSnapShot As Boolean

'Used by report 'rptRatesByWeek'. Can be reused without conflict
Public WeekEndDate As Date, strEmplName$

Believer, JimMorgan and all:  this is a very critical thread to me as well as
you guys, so i would like to throw in some points.  when we get a resolution
that is acceptable to you, Believer, please let me know (email in profile) and i will award additional 200 pts.   (also, i will be reading the comments too, so i should see when an answer is posted).  lots of good stuff so far to look into.   ---ssam
I don't believe that the problem is actually a shortage of memory, like it got used but not released.  I believe instead that there is a true flaw in the programming of Access where instead of setting a pointer to 'All Except This value' it sets it to 'This value', (I'm using vague terms on purpose, so as to convey the concept only).

It's like those problems they have had with cash machines that interrogate your account to see if you have enough to handle a $2.89 charge, find that you have 2,422.33, but instead of setting

    Acct = Acct - Chrg,

they set

    Acct = Acct - Acct

because the programming was done on Friday instead of Wednesday, when they would have been more alert...
Believer:  Public variables - We use a lot of those.  They save resources and make the program run faster.  Therefore that are efficient.

Our motto: if a string may be used more than once in code, we make a public constant for the string inside a code module.  We have one large module that is loaded once, the first time that a constant is needed.

If the constant only is related to a class module, we put it in the header of the class module.

If we need to use a number, we convert that to a constant given it a name that makes it easier for reading.

We also create a constant for the name of every database object, tables, queries, forms, etc. that we use.  It makes programmer easier and more readable.

We have over 750 contants and 50 variables predefined.

If you are going to make a variable public, you really should put them on separate statement lines and explicit define them.  Don't use strThis$ but strThis as String, which is preferable.

One the module is accessed and loaded during an Access session, those constants and variables are placed at the top of the heap and are referred internally by pointers after loading.

I hope that you also use Option Explicit at the top of each module.

The reference to buffers relates to the amount of internal Access space that is taken to store temporary values, etc.  Like an internal stack.  Access will also allocate an amount of memory space for swapping out part of the program.  When this space becomes full, the hard drive is used for swapping.  Some people call it buffers.  There are read buffer settings for reading data files and such but unless you have played with the settings, I don't think that this is a problem.

The garbage part comes in to play with Access keeping all changes made to a control or a value.  Even values are buffered so that you can use the me.undo or control.undo to recover the last value.  The undo icon will let you recover several changes back.  In a session those changes are not thrown away or cleared out.

Another session resource hog are SQL queries.  Every time they are run, Jet has to compile and optimize the query.  This takes up resources.  The nice thing about stored queries is they are compiled and optimized once and subsequent runs don't require the overhead.  When you repair and compact your DB, Jet recompiles and optimized all stored queries.

While we are talking about saving resources, every time you reference an object, Access has to load all the information about the object.  If you use the With Object/End With function, the object is only referenced once and does not have to take the time and resources to do it over and over.

Even 'Me' doesn't have to be used over and over.  It is a shortcut reference to the current form but it still takes resources to reference it each time.

Using the reference Active.Control, Parent, Active.Screen etc. will save time and resources.  Use them where ever you can in a class module or event property line.

Ever time you Set a control reference, you should Kill that reference before you leave the procedure.  This reallocates resources.

You asked in an earlier comment if there was a better way to remove popup forms other than what you were using.  I not aware of any.

With all of that said, let's get back to the problem at hand.

Let's verify that exactly a certain sequence of code is causing the problem and not really using up the resources, which I believe all of us think is not the real problem.

If you open a session of Access and this app and the very first thing you do is run this routine, does the error occur?  If you don't load anything, open with the shift key, and run just the report procedure, does the error occur?

If your answer is yes to either of these, then is something specific to your code.  Please post all the code up until the time that the error occurs so that we can look at it.

Apparently only one report causes the problem.  Right?  It you run just the report with no code leading up to it, what happens?  This may help determine if it the code run outside of the report vs the class module behind the report.

I know that it may take some time, but how about rebuilding the report from scratch?  I've seen complex forms which I could not get to work and so redesigned the report from scratch and they worked perfectly.  Except for the output, most of a report works just like a form.

That the get preliminaries routine that is causing the problem.  Have you tried to get all the information that you need at one time and perhaps put the data in a table with as much preprocessing down by queries against the table before going to the report.  Join the table in the report query.

It could be that the report is just too complex.  Have you tried to break the report down and turn off half the functions to see if this has an effect.

There are just so darn many variables which could be causing the problem.  I think that we have been chasing our tails with the 'memory error'.

believerAuthor Commented:
I think this is critical to several of us.  Please keep in touch with this one. I would probably offer more points as well to solve this one.

I agree with you and JimMorgan. I don't  thinks this is really a memory problem either.

Thanks for that detailed response !

Yes, I do use option explicit

No, I didn't know there was a difference in "$" and "As String". I will stop that practice.

Thanks for the info on buffers.  I don't see my swap file even being used…

SQL queries: I thought I was a real smart guy not using queries or macros. I see the end result of the GUI query builder as a SQL statement, so I just write my own.  I don't use macros, because I'm more comfortable with code.

I do use the With End/With function when I can. Not to say some of my older code might need to be changed.

When you talk about killing a reference to a control, are you meaning setting it equal nothing ?
I think a redesign of the form is at hand.  Instead of calling the PopUp form three times to get the criteria, I am going to build one form that gets all the criteria at once. Although I think it should have worked the way I originally designed it.

Thanks Experts,
Yes I talking about setting an object, not necessarily a control, to nothing.

Dim rstThis as Recordset
Set rstThis = ....


Set rstThis = Nothing.

Whenever you are finished using an object dimmed and set, set it to nothing so that it is removed from the application stack.

I learned a while ago that although you think that something should be prefectly acceptable but you keep having problems no matter what you change, is the time to redesign it.  Usually through experience, you will find the redesign working better and more efficiently than the first.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
believerAuthor Commented:
I gave this one a couple days after it got quiet, and have decided to award the points to JimMorgan for his many detailed comments.

My “work around” was to redesign the form, and it actually worked out better than the original design. I think someone mentioned that might happen….

If I had to guess, I think the problem with access is the “acDialog” argument when the form opens for the second time.  I tried it without this argument, and did not get an out of memory error.  It could be the way I tested it that prevented it (Pausing the code).  Irregardless I think this is an inherent problem to Access.

Thanks again for all the comments,
Believer:  I glad that the 'work around' did the trick.  As I had suggested earlier, I had great results when I have done this myself.

There are a lot of minor problems with Access and once you learn them, you just stay away from them.  All programs have problems of some type.  So this is not unique just to Access.

There is some internal cleanup (not much) that is done within Access.  Sometimes it needs to close everything out before it can properly proceed.  That is what DoEvents is used for.  By pausing the code, you did a manual DoEvents.

With faster systems, you might find out that more DoEvents may be required.  Although acDialog is supposed to pause the code for you, I always put a DoEvents statement afterwards.  Actually I prefer NOT to open a popup form with acDialog.  I just make the form Modal and PopUp if I don't need to leave it open to get a value.  If I do need to leave it open, when I'm finished entering info, I hide the form and then in the code that called it, set up a loop with DoEvents checking that the form is still open and visible.  After the loop is closed (form is closed or invisible), I check to see if the form is still open.  If so I get my value and close the form.  Then DoEvents to allow the form to complete close before proceeding.

Ssam:  Did any of this help with your situation?  If not, then perhaps you should post more information about your problem in a question so that we could try to solve your problem as well.

just checked it out now.  will let you know jim.  thanx!  i'm putting the extra promised points up for you in either event.  ---ssam
i think that the issue with wizards put us on the right track to correct the situation.  still plan to
                   try the "Set rstThis = Nothing" trick as well.  we're not fully fixed, but its certainly better.  thanx
                   again!  ---ssam
                   (p.s., i will post this comment to the other question as well).
I resolved the "There isn't enough free memory to update the display.  Close unneeded programs and try again." error that I was receiving any time I would attempt to run a report within Access by adjusting the resolution on my monitor and then changing it back.  I received this idea from wesleystewart's second comment on this string.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.