Solved There isn't enough memory to perform this operation... (Access 2013, 64-bit on Windows 11) (1 Viewer)

[Simon_C]

I have here an old Access Database system which has been running for the best part of 20 years, quite successfully. For the best part of the last ten years it's run on the 32-bit version of Access / Office 2013 running under either Windows 7, 8 or 10 without many problems at all. We'd stuck to the 32-bit version of Access / Office because it's only quite recently that everyone using it has migrated to a [machine running a] 64-bit operating system.

I wanted to try to get the application running under the 64-bit version of Access 2013 before I even thought about moving it to Office 365 and I've now got a PC with the 64-bit version of Access 2013 running under Windows 11.

However, while the database opens without an issue, running anything is a different kettle of fish. I can generally open tables manually, and run queries and reports manually. All the problem seem to be with Forms. I even get the "There isn't enough memory..." error when I open certain forms in Design Mode (and once it's appeared if you close the message box it immediately reappears). If I try running anything 'for real' then if there's an error I can't do anything in the debug window to see what the problem is because the "There isn't enough memory..." error box appears there too, and keeps appearing.

The Windows 11 PC has plenty of memory so it shouldn't be an actual lack of memory. If I look at the Task Manager, Access seems to be using about 350 MB and Task Manager reports that total memory use is at about 7%.

Does anyone have any ideas what I could look at?

Edited to add: I had this problem immediately I installed Access 2013 on the Windows 11 PC but a variety of Office updates have since been applied to the PC and this doesn't seem to have changed anything.

 

[AHeyne]

Just some ideas:
- First make a backup of the file.

- When you're in the VBE (Code):
- Can you compile it without errors?
- Are there some unusual/non-standard references in the database?

- If it is a MDB, try to convert it to ACCDB.
- Try to decompile/compact it.

 

[The_Doc_Man]

The question for opening forms is to determine what code is running, starting with the form's _Open, _Load, and _Current routines. The _Open event has a parameter (Cancel) so you do have to pay attention to the issues of calling 64-bit routines with parameters. The _Load and _Current don't have parameters so in theory cannot run into interface incompatibility.

There is also the issue that not all 32-bit libraries were converted for 64-bit versions. Microsoft is like that, abandoning things injudiciously when they think the cost/benefit ratio is favorable to THEM (never mind US). Therefore, you might have problems calling some library that isn't fully happy with the 64-bit environment. When you compile, if you have an incompatible call you should get errors. AHayne's suggestion to decompile is also reasonable as that operation tends to reveal hidden flaws obscured by Access thinking it has current code when in fact it does not.

Have you searched for the many articles in this site regarding the "convert to 64-bit" topic? You would get over a hundred hits in general and specific articles. The SEARCH option is to the right in the menu bar.

You can find a few articles of interest regarding memory usage in the "Similar Threads" section, which is based on keyword matching. It is always possible to find a few gems in that list.

 

[Simon_C]

Thanks for both replies.

I haven't tried de-compiling it, I'll give that a go.

I have already tried compacting it. When I first started messing with it, it did compile OK after I adjusted a couple of API calls which needed tweaking. It is ACCDB already. I also tried creating a new empty database and copying all the objects into that but that didn't make any difference. I had to add in a few references but I don't think any of them are particularly outlandish (i.e. it's all Microsoft stuff) but I'll take a closer look, it may be there are further tweaks to be made (i.e. alternative versions of the same libraries).

Yes, I'm sure there will be issues to address as regards the conversion to 64-bit but I wasn't expecting obstacles such as being unable to open to forms in design mode (if there's something wrong, how am I expected to change it?). I have been looking at references to converting to 64-bit but I must admit I've mostly been looking for those in conjunction with memory (or at least reported as memory) issues.

 

[GPGeorge]

Thanks for both replies.

I haven't tried de-compiling it, I'll give that a go.

I have already tried compacting it. When I first started messing with it, it did compile OK after I adjusted a couple of API calls which needed tweaking. It is ACCDB already. I also tried creating a new empty database and copying all the objects into that but that didn't make any difference. I had to add in a few references but I don't think any of them are particularly outlandish (i.e. it's all Microsoft stuff) but I'll take a closer look, it may be there are further tweaks to be made (i.e. alternative versions of the same libraries).

Yes, I'm sure there will be issues to address as regards the conversion to 64-bit but I wasn't expecting obstacles such as being unable to open to forms in design mode (if there's something wrong, how am I expected to change it?). I have been looking at references to converting to 64-bit but I must admit I've mostly been looking for those in conjunction with memory (or at least reported as memory) issues.

You can try pressing and holding the Shift key while opening the accdb to bypass start up code. If the form's don't open in design view at that point, you may have corruption in the accdb. In that case, the most recent backup will be your next step.

 

[arnelgp]

did you Uninstall the x32 version before installing the x64?

 

[MichealDon]

May you try to do "Compact and repair" for the database first.

 

[AHeyne]

Ok, the fact that you have already converted api functions from 32 to 64 bit suggests that the problem could well be that something was not converted properly.

I would set breakpoints in the code and debug to find out exactly where the error lies.

 

[Pat Hartman]

Go back to the original version. Make sure it compiles. Fix the API calls. THEN convert.

 

[Simon_C]

did you Uninstall the x32 version before installing the x64?

The computer I'm running the 64-bit version of Office on has never had any other version installed.

 

[Simon_C]

May you try to do "Compact and repair" for the database first.

Thank you, but I've tried a few of those!

 

[Simon_C]

You can try pressing and holding the Shift key while opening the accdb to bypass start up code. If the form's don't open in design view at that point, you may have corruption in the accdb. In that case, the most recent backup will be your next step.

This, I think, was it. I mean I did get problems if I tried running the start-up code but I also had problems in design mode if I didn't, so I've gone back a fair way and using that older version seems to solved the more peculiar errors I was getting. I now might try picking a more recent backup but given that the application has been (and is) running without issue under 32-bit Access I've no particular reason to assume that any such corruption has happened between the last backup and the current version, whatever it is could have happened months ago so, it might just be easier to stick with what I've got and re-apply any of the minor code changes that have been made more recently.

So anyway, the code on the main form in the application now runs well enough to display some data which looks like it's OK. There's plenty more to test, of course. I've so far hit problems with the number of records being fed to a subform exceeding some resource behind the scenes (which I've managed to solve) and one problem which appears to relate to the number of entries on a pop-up menu (which I'll need to have a think about). But those are problems of the type that I might well have expected to come across, so that's all fine.

Thanks to everyone for your suggestions and help.

 

[The_Doc_Man]

Here's a thought - for code sections (not specifically YOUR code sections, but in general), which have generally been shown to be subject to occasional corruption, it might be worth while in recovery attempts to try to export module code AS TEXT, then read over it using NOTEPAD or some other text editor to assure that it appears to be intact, then try to import that code (as text) into a module, perhaps as cut/paste from that editor if you don't want to wholesale import the text to replace the module contents. If there are logic errors in the code, this won't fix them. But if there was corruption, you could take this approach as a way to fix it since it is starting almost from scratch.

 

[Simon_C]

Here's a thought - for code sections (not specifically YOUR code sections, but in general), which have generally been shown to be subject to occasional corruption, it might be worth while in recovery attempts to try to export module code AS TEXT, then read over it using NOTEPAD or some other text editor to assure that it appears to be intact, then try to import that code (as text) into a module, perhaps as cut/paste from that editor if you don't want to wholesale import the text to replace the module contents. If there are logic errors in the code, this won't fix them. But if there was corruption, you could take this approach as a way to fix it since it is starting almost from scratch.

Or even for digital comparison with a set of master versions (in text form) though obviously that would be more practical at a point where code wasn't changing frequently and significantly.