Error Message on my Report - Not enough memory to display report.

[LeLe]

I have put hours and hours into my application, and all seemed to being going
well. Suddenly, one of my reports won't run any more and instead gives me
the error message " There isn't enough free memory to update the display.
Close any unneeded programs and try again". I get this message even if
Access is the only program running and the report is the only thing open.
The underlying query is working fine. I have tried removing individual
controls and even eliminated all controls from the report but the error
message continued.

I have tried the compact and repair utility but it didn't help. What can I
do?

HOw can I protect myself from this kind of thing happening in the future?
This report is used to generate work tickets for our factory and now it is
not functioning. I have a backup version, but is not as complete as the one
that is giving me the error message.

Any help, suggestions, or ideas are greatly appreciated.

 

[Tom Wickerath]

Hi LeLe,

It sounds like your report might be corrupt. Try creating a new Access
database and importing all objects into it. I give explicit instructions on
the lower half of page 3 of a Word document that I call Access Links. You are
welcome to download a zipped copy, here:

http://www.accessmvp.com/TWickerath/

If this does not work, then please post back. I've got some other
suggestions, using the undocumented SaveAsText / LoadFromText commands, that
you can try as well.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[LeLe]

Hello Tom
After reading your response here's what I have done so far:

Created a new DB, and turned off the name auto correct option.
Imported my tables - no problem
IMported my queries - no problem
Imported my forms - 3 would not import - error "name conflict with exsisting
module project or object library
Imported my reports - all came over, including the problem one that will not
display - with error message, not enough memory to display.
Ran repair and compact.
Ran compile.

Thanks so much for you offer of on going help. As you can see, I still need
it!!

 

[Tom Wickerath]

Hi LeLe,

Imported my forms - 3 would not import - error "name conflict with existing
module project or object library

That's a strange error. Are you using any reserved words or special
characters in the object (an object is a table, query, form, report, macro or
module) names of your database? Access MVP Allen Browne offers a nice utility
that you can use to scan your tables for the use of reserved words in table
and field names, but it currently does not include other object types in it's
scan. He also has an extensive list published here:

Problem names and reserved words in Access
http://allenbrowne.com/AppIssueBadWord.html


Are the names of the three forms that you cannot import included in Allen's
list?

Imported my reports - all came over, including the problem one that will not
display - with error message, not enough memory to display.

Can you now open this report without an error?


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[LeLe]

The 3 forms were called "PatternsFabrics", "PattermsFabricAddNew",
PatternsFabricsAddNewColor" - (We are in the interior design business and
manufacture draperies). I couldn't see any "bad words" in the forms but no
big deal, the forms were minor, and I can recreate.

At the present time, I seem to have solved my problem by creating a new
report, basing it on the same query and then copy pasting the control over
from the report that stopped working to this new one.

Unfortunately, this whole experience has left me a bit shell shocked. In
the past we wrote up work orders by hand, and I have been the one pushing to
automate the process. Fortunately, no one found out about this problem,
since we are still not using the automate work ticket on a regular basis yet.
What if this happens again down the road and causes a real problem in our
factory. What can I do to protect myself and my company?

Thanks

 

[Tom Wickerath]

Hi LeLe,

Sorry to read that you felt shell shocked, but glad to see that you have it
fixed now.

The 3 forms were called "PatternsFabrics", "PattermsFabricAddNew",
PatternsFabricsAddNewColor"

These names certainly should not have caused a problem. However, it appears
as if you may have two copies of the same form, "PatternsFabrics", one to
open to all records and one to open to a new record only. You can use the
optional DataMode argument of DoCmd.Openform to open this form to a new
record, without having to have a similar copy of the form. Something like
this:

DoCmd.openForm "PatternsFabrics", DataMode:=acFormAdd

versus just:

DoCmd.openForm "PatternsFabrics"

What if this happens again down the road and causes a real problem in our
factory. What can I do to protect myself and my company?

Make frequent back-ups of your database, and test them as well.

Is this database shared on a network drive? If so, one of the most important
things that you can do to help prevent JET database corruption is to split
the database into two separate databases: a back-end (BE) .mdb file and a
front-end (FE) .mdb file. If you are using the new ACE format in Access 2007,
the same concept applies, just substitute .mdb in my last sentence for
..accdb. The BE file contains the shared data only. The FE file contains all
other objects: queries, forms, reports, macros, modules, and any local
(non-shared) tables.

A copy of the FE application file should be installed on each user's local
hard drive, so that two users are never using the same copy of the FE
application file. Please see my Multiuser Applications paper, available here,
for more details:

http://www.accessmvp.com/TWickerath/articles/multiuser.htm


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[LeLe]

Hi LeLe,

Sorry to read that you felt shell shocked, but glad to see that you have it
fixed now.


These names certainly should not have caused a problem. However, it appears
as if you may have two copies of the same form, "PatternsFabrics", one to
open to all records and one to open to a new record only. You can use the
optional DataMode argument of DoCmd.Openform to open this form to a new
record, without having to have a similar copy of the form. Something like
this:

DoCmd.openForm "PatternsFabrics", DataMode:=acFormAdd

versus just:

DoCmd.openForm "PatternsFabrics"

Thanks I know you are right, I was tring to make the form similar but just different enought that it was clear to the user they were add new data. Sometimes, it is confusing to know where you ( as the user are)

Make frequent back-ups of your database, and test them as well.

Is this database shared on a network drive? If so, one of the most important
things that you can do to help prevent JET database corruption is to split
the database into two separate databases: a back-end (BE) .mdb file and a
front-end (FE) .mdb file. If you are using the new ACE format in Access 2007,
the same concept applies, just substitute .mdb in my last sentence for
.accdb. The BE file contains the shared data only. The FE file contains all
other objects: queries, forms, reports, macros, modules, and any local
(non-shared) tables.

A copy of the FE application file should be installed on each user's local
hard drive, so that two users are never using the same copy of the FE
application file. Please see my Multiuser Applications paper, available here,
for more details:

Thanks, this makes sense. I am familar with the database splitter, but I
only used it when the back end got large, or when I wanted to continue to
develope the front end. I never considered it as protection but again this
makes sense.

Thanks again for your help.

 

[Tom Wickerath]

Thanks, this makes sense. I am familar with the database splitter, but I

only used it when the back end got large, or when I wanted to continue to
develope the front end. I never considered it as protection but again this
makes sense.

Thanks again for your help.

You're most welcome. Glad I could be of help. Don't forget to backup your
data using whatever schedule would not cause you too much pain if you had to
re-enter data since the last backup. Periodically check your backups as well.

Here is a fun little tune that I hope you will never have to sing to yourself!

http://www.accessmvp.com/TWickerath/downloads/yesterday.doc


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html

 

[Pete D.]

I have had this error on a report I had frequently changed, added and
removed things to its design. Someone here suggested running the /decompile
option on the datafile and it cured the problem.
http://www.mvps.org/access/bugs/bugs0008.htm

Pete D.

 

[Tom Wickerath]

Hi Pete,

Yes, the /decompile trick is the first thing I cover in the section of my
Access Links.doc Word document, which I referenced in my first reply.
Sometimes it works...sometimes it doesn't work. I've even experienced
situations where importing all objects into a new container and attempting to
use the undocument SaveAsText / LoadFromText did not fix the problem, but,
copying the controls from a corrupt form or report to a new form or report in
the same database did fix the problem. It's kind of a guessing game sometimes
as to which strategy will work, if any of them work.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[Pete D.]

Sorry,
I'm stuck with outlook express on this computer (work laptop) and didn't see
your first reply, sometime it drops parts of the conversation. As I
frequent this group I was wondering why you hadn't mentioned it. Again Tom,
sorry about the foul.