[AccessD] There Isn't Enough Free Memory error message

And I have found decompile to be much more reliable than everybody makes it
out to be.  OTOH, I had it completely hose a db one time.

John W. Colby
www.colbyconsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Doug Murphy
Sent: Friday, October 31, 2003 2:26 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] There Isn't Enough Free Memory error message


Ken,

Thank you for your thoughts.  I use decompile when I start getting odd
behaviors, but have had it fail with form coruptions. I saw a message
the other day on this list about the total number of controls that could
be put on and removed from forms and reports during their life after
which they wouldn't work anymore.  It seems there is a bunch of stuff
that accumulates with Access Objects through their life that can
eventually cause problems.

When we ran into this problem yesterday with the insufficient memory
thing and it turned out to be a form coruption I started wondering if
there were some basic maintenance tasks that could be done periodicly to
increase product reliability and avoid these problems, which always seem
to happen at the worst time.  Maybe the name Murphy has something to do
with it.

I read somewhere, Kaplan's site I think, that decompile has its own set
of limitations and risks so it is not the universal tool, but it has
saved my tail several times too.

Doug






-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Ken Ismert
Sent: Friday, October 31, 2003 10:20 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] There Isn't Enough Free Memory error message


Doug,

I would recommend decompiling your development mdb. Steps:

 1. Backup your mdb
 2. Decompile. To do this, run Access with the /decompile switch:
      MSACCESS.EXE your.mdb  /decompile
 3. Compact and Repair.
 4. Compile your VBA project.
 5. Make your mde and deploy

I always decompile:

 * Before deploying updates
 * When I get the 'Bad DLL calling convention' error
 * Anytime I sense any weirdness at all with VBA's behavior

I will usually decompile:

 * After extensive code revisions
 * After adding/removing objects containing code

Decompile has fixed a long list of corruption issues for me. I've relied
on it for over a year now, and I trust it, at least in A2K. It is on my
list of 'best-practice' methods for maintaining trouble-free code.

-Ken


-----Original Message-----
From: Doug Murphy [mailto:doug at murphyscreativity.com]
Sent: Friday, October 31, 2003 10:52 AM
To: 'Access Developers discussion and problem solving'
Subject: [AccessD] There Isn't Enough Free Memory error message


Folks,

We just experienced a weird error in a database that has been working
for several years.  This is a product that we distribute as a runtime
and are just getting ready to make a presentation on at a conference.
Last night in putting it on the laptop we got an error message saying
"There isn't enough free memory to update the display. Close unneeded
programs and try again".  I did a quick Google search on this and found
that there is a problem with Access 2000 form with it's picture property
set to a gif image.  This isn't the case in our situation.  We are using
AccessXP, an MDE file in runtime mode.  The form has a small jpeg image
on it.  After playing with the DB for a while, Pressure mounting as the
flight leaves at 8:00 the next morning, I found that the opeing splash
screen that runs some initialization code was corupted.  I copied the
form components and code into a new form and it seems to be working.

We have not changed this form for quite a while and having it all of a
sudden corrupt doesn't give me a warm fuzzy for something we send to
folks to install on their computers.  I retested the new install on all
the versions and permutations of WindowsXP with and without Office XP
that we have on our test systems.  So far it seems to be working.  Has
any one else had an experience like this?  Any suggestions for
preventing this type of behavior?  With a database that is under
continual development, would it be a good practice to import all objects
into a new container every so often to prevent this type of behavior?

Thanks for any thoughts.

Doug








_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com