Access 2016 Out of Memory

I have workstations running windows 10 x64 office 2016 x32.

even though most users would only need the 32bit version, some would need the 64bit version especially dealing with larger data sets.
uninstall office and install the 64bit version and it should work better

32bit applications can't address more than 4gb so having 32gb won't get you far (though the OS supports it) without using a 64bit application that can address larger memory spaces

I would strongly recommend against 64bit office as there are very few ActiveX controls that will work in that enviroment, and most people do not need more than 4 GB for a normal Access application.

I would start out by building a new front-end from a blank database and importing all of the current FE objects into that new file.  Then compile everything and compact and repair.  This error message is common when you have a corrupt project file or even just a single corrupt object in the FE.

Dale

I'm with the option of removing the 32 and install the 64 bit (whole office or just access).

can you try this scenario: since most of your computers are 32g, did you tried to open the same file on other computers? does the same error on other machines? or they work fine? maybe there is other software on your computer that is consuming memory or making conflict with access.

I would agree with Dale - don't install Office 64 bit. Larger datasets are relevant to Excel, but not Access. An Access database can be up to 2 GB regardless of the "bitness" of the Office install.

If you're having troubles importing objects into a database try to perform maintenance on the database first, as Dale suggests. Also be sure to perform these operations on local copies of those databases. Don't use networked copies for things like this.

Yes I agree that 64bit installation of office is not a solution due to the extensive programming my applications have with ActiveX controls. I have already rebuilt the front end several times and done decompile, compact & repair db, compile approach. This has fixed issues in the past. Doing this on a local copy of the db front end does not resolve the issue as well. The issue seems to be when creating new forms and adding additional control objects. It seems that access is acting like it has reached some type of capacity limit somewhere, but there is no notification of what or where the error is occurring.

Have you done as Dale suggests and create a new, blank database and import everything into it? Sometimes the container gets corrupt, and the only fix for that is to create a new one.

Access has limits on the number of objects it can contain, and those are "lifetime" limits. If you're in the habit of creating and deleting Forms, for example, it's possible that you have reached one of those limits. However, you generally don't get out of memory errors when that occurs, you will instead receive an error message stating you've reached those limits - something like "Access can't add any more Forms".

If you have already rebuilt, then the only other thing I could suggest would be to repair or reinstall Access, and make sure that you're fully up to date on all your Office and Windows updates.

Yes I have rebuilt the database several times. The out of memory error occurs randomly. I don't think the issue is related to the copy of access installed considering I have a team of developers who get the same issues periodically on different workstations.

Sounds like too many forms are open simultaneously.   Close all forms before opening vb editor.   Another thing you can do:   set any subforms not being used source object to null.  You are limited to 2 gigs of ram in access.  Restarting computer will refresh the memory leaks access has over time.

Access has a 2 GB database limit, but is not limited in regard to RAM or other memory.

Scott, I believe Joshua is referring to the RAM available for use by Access, which is also 2GB, although there appears to be a work around which will make Access, like the rest of Office, Large Address Aware, allowing access to up to 4GB of RAM.

I've never heard of that limitation (i.e. the RAM limitation). Are there any source links you could point to?

https://support.office.com/en-us/article/access-specifications-0cf3c66f-9cf2-4e32-9568-98c1025bb47c#__toc296343505 I have tried many ways to get around these limitations.   I am maxed out on my access database even with all of my tables running on sql server as  linked tables. I also forgot to mention application.echo.  doing this during screen refreshes will help alleviate access memory usage during loading and refreshing on GUI.   Just remember to set application.echo = true when error handling.  If you want to see the memory limitations yourself:  download vmmap and check out what your own personal copy of access is using.   I use this tool to assist me in finding where access is using memory most. Here's another one:
https://dba.stackexchange.com/questions/167731/bypass-ms-access-2gb-file-size-limitation

That's the max database file size, as I indicated. I know of that limitation. I'm not aware that it has anything to do with open forms, or anything of that nature. Unless I'm mistaken the size of an Access database doesn't grow substantially when you open a form or report. It stays essentially the same unless you (a) add data or (b) add objects or (c) something is wrong with it.

Download vmmap and open it.   Select access as the process you want to monitor.  Once access and vmmap are open just open forms and watch available free memory drop.   You will understand that ram usage is limited to 2 gb.  If I'm wrong please let me know :)

Joshua,

I Downloaded vmmap and opened it.  I selected access as the process you want to monitor, opened 4 forms simultaneously and still have 1,264,704k of ram free.

Yes and open a 5th and refresh.  That number will decrease.

if you look at my previous posts you will see that its not a matter of having too many forms open while running the application, but having an issue with too many modules or forms in the front end and getting an out of memory error when adding new lines of code, forms or modules. I was able to bypass the issue by creating a database that only has modules in it and adding it as a library reference to my front end database application that only has forms, queries, and linked tables. I'm not sure if this is a permanent solution, but it works for now. any other suggestions or solutions are welcomed.

@slogwood,

Interesting that moving the code to a library would have this effect.  How big was the Access database which contained all of the objects?  How big are the two files now?  I'll run this up the flagpole and see what some other experts have to say.

Dale

The original database was around 115mb. it had linked tables from a separate access database and SQL server database. the new front end database is 102 mb, the modules database is 12 mb, and the front end still has linked tables from another access database as well as SQl.

I'm trying to get some from the Access team at MS to look at this.

Were you getting this error when attempting to add stuff to the VBA code modules (in the VB Editor) or was it ocuring when you were running the application?

it does not occur when running the application. it occurs during the following scenarios...

1. adding new modules or forms (creating new or importing from separate db).
2. adding or editing code in form modules and stand alone vba modules.
3. adding additional control objects to forms.

So, this is definitely a VBA issue.  My POC on the Access Team indicates:

This definitely sounds like he is hitting the 32K limit on identifiers in VB project.

Moving code to a library database addresses the problem be moving some of the identifiers to a separate project (with its own 32K limit).

An identifier is a module name, a function name, a form name, a control name, a local variable, etc.

Creating library databases to reduce the size of projects is the best solution I know of.

I had never heard of this 32K limit and some of my fellow MVPs have also indicated that they were not aware of it as well.  I'm trying to get a reference to a description of this limit, but trust me, my POC at MS knows what he is talking about.