out of memory, but not out of memory??

[gymbeef]

Not sure what I did or what's changed, but a previously OK app is now giving me headaches:

During the course of running an app under Access (running within Access, not as a standalone), I get an Access Error message that says I'm out of memory, and to close some open programs and try again. My actual memory usage isn't really maxed out - according to a memory monitor I have running concurrently, I range from 60M (23%) free with Acess alone running to 37M (14%) free with Access running my app. And I see no change or "spike" when the error message pops up - the graph stays pretty much flat at 14% throughout no matter what my app is doing.

I'm guessing its not actually the total memory usage its looking at since there's still free RAM left, but some portion that Access has reserved for itself which is "full". So whats really goin on here? How do I fix and\or prevent the problem? Or rather, where do I start looking to find the *real* problem, since this is really just a symptom?

For reference: I don't think I have any extraneous variables being created as I have Option Explicit statements in every module, and I don't think I'm using any variant data types. None of my back-end data manipulation is that complex or involves that much data. So where's all this memory goin to?

Thanks in advance

 

[RickSpr]

Most likely cause: Do you have a recursive procedure or set of procedures? It could be that you're getting an infinite recursion because your terminating condition never arises. That will consume your entire stack space and cause this problem.

Does this only happen after you've been using the app for a while? If so, it might be a "memory leak."

Does your app use DAO? There's a known memory leak bug in DAO whereby, if you fail to set certain object variables (particularly for Database and Recordset objects) to Nothing before they go out of scope, the object isn't released and becomes a dangling reference. (The usual symptom for this problem is that Access minimizes instead of shutting down properly.)

Which memory statistic are you monitoring? If it's available physical memory, it could be that your virtual memory (swap file) isn't large enough, and is unable to grow. Check Control Panel>System>Virtual Memory (in Win95/98/ME) to make sure you're letting Windows manage virtual memory, and make sure you have plenty of hard disk space for it to extend into.

(Unlikely, but...) Are you using any home grown Class modules in a structure where two or more objects contain object variables referring to each other? If so, you've probably formed a referential loop and the objects never get freed. This is another memory leak. To fix it you have to set one of the object variables in the loop to Nothing before you release the last outside reference to it.


Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[Hap007]

Dear gymbeef,

A couple thoughts here.

1) In a Windows world, when you are at 14% free, Windows is really in trouble and out of memory. Seems like any time resources get below 65%, things start to slow down. Particularly with Win 98 and Win ME. What version of windows are you running?

2) You may also be running low on disk space and the image of the memory can not be written properly.

3) Check your Windows\temp directory for unused files and delete them.

4) If you are using VBA Code and opening RecordSets and the like, make sure you Close the RecordSet and set to nothing before exiting the code module, otherwise memory starts getting sucked up by Access.

Hope One of These Items Helps You,
Hap


Access Developer

http://www.fcs-software.com/fcsaccessdev.html

-
Specializing in Access based Add-on Solutions for the Developer

 

[gymbeef]

Thanks for the suggestions guys, but upon closer examination my problem seems to be something very specific.
It seems related to the clipboard and not "memory" in general. Here's whats happening:

I have TextBox1 that gets filled with a string value, and that string is also copied to the clipboard (see below for code). When I go into TextBox2, its set up to select all the text therein (see below). If I do CNTRL-V (paste) at this point, it should replace the selected text in TextBox2 with the contents of the clipboard. But CNTRL-V generates the error. I'm guessing some kind of clipboard conflict occurs in trying to replace the selected text with whats saved on the clipboard.

[TextBox1 routine to put contents on clipboard]
...
Me!TextBox1.SetFocus
L = Len(Me!TextBox1)
If L > 0 Then
Me!TextBox1.SelStart = 0
Me!TextBox1.SelLength = L
DoCmd.RunCommand acCmdCopy
Else
End If
...

Private Sub TextBox2_Click():
L = Len(Me!TextBox2)
If L > 0 Then
Me!Text113.SelStart = 0
Me!Text113.SelLength = L
Else
End If
...

{Manually entered CNTRL-V}

Error!

 

[RickSpr]

Do you realize that the code for TextBox2 is trying to set the selection in Text113? That right there will raise error 2185 (Can't reference a control unless it has the focus). I don't know how that can become an Out of Memory error, but I'd fix that first and then see what happens.



Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[gymbeef]

Oops! That was just a typo. My control was originally numbered Text113, I changed it to TextBox2 for the example to make it more clear, and wasn't paying close enough attention.

 

[RickSpr]

OK, but this illustrates why it's really better to cut and paste your code, rather than edit it. Mistakes in the editing waste everybody's time, whether it's because you introduce syntax errors that distract us or because you inadvertently cut out the real problem, thinking it's irrelevant. Besides, "Text113" doesn't seem any less clear to me than "TextBox2"--they're both just arbitrary names.

Here's the most likely possibility: An experiment shows that the Click event for Text113 occurs before its GotFocus event--so if you're actually clicking in Text113 to shift the focus from TextBox1, the paste isn't happening in Text113 at all. In fact, the paste would be applied to TextBox1, but that control is in the process of losing focus and can't go through its normal update cycle (BeforeUpdate/AfterUpdate events). Access often goes a little nuts when you force it into this kind of conflict--I've seen it many times.

To test whether this is the problem, try tabbing to Text113 before you click on it. By getting the focus set to it before you click, you'll avoid creating the conflict. If tabbing first works properly, that pretty much verifies that this is your problem.

Otherwise, here are some more ideas:

The problem happens when you press Ctrl-V. That's not necessarily the same thing as saying it happens during the paste operation; it could be coincidental. So you should still check the Virtual Memory properties and your disk space to make sure that's not the problem.

Next, check whether you have an AutoKeys macro that captures ^V. It could be you're inadvertently calling some other kind of procedure and entering into an infinite recursion.

Next, check whether either Text113 or the form has a KeyDown/KeyPress/KeyUp event procedure. If so, it's probably at fault; if necessary, put a breakpoint in there and see if it's looping inappropriately.

If it really is something to do with the paste operation, it could be that you don't actually have a text format on the clipboard, and Access is trying to store a binary object into the text box's Value property, which is a Variant (all control Value properties are), but then the text box goes nuts trying to render it as text. If you're really doing things in the order you said, though, I don't believe this is the problem.

Just to be thorough, you're actually using Access text boxes here, aren't you? That is, you're not borrowing some kind of edit control from a 3rd party package, meant to be used with VB, are you?

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[fneily]

I have a large Access app that when I have the Internet up, I get "Out of Memory". But this is because of the O.S. I have - Windows Me. Someone above asked what O.S. you have and you haven't responded. Remember, Windows 95, 98, 98se, Me are not 32 bit O.S.'s. They're app shell's around DOS - 16 bit. They cannot make VM's. Also, there has to be alot of 32 to 16 bit translation going on between the core O.S. and Windows. And, as mentioned, Windows uses a huge amount of your memory, unlike the best O.S. out there Unix. (Your phone calls go through Unix, not Windows.). Run your database on Windows 2000 and see if you still get the error.

 

[RickSpr]

Fneily,

Your characterization of Win 95/98/ME as 16-bit was true of Windows 3.1, but it's flat wrong for these OS's. See the Windows xx Resource Kits for factual information about the internal workings of the operating systems. "Facts" from *nix zealots are not necessarily reliable.


Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[fneily]

Have you looked at the actual assembly SOURCE code for DOS 7 and Windows XX?

 

[psemianonymous]

I'd first like to say that I love Linus Torvalds. He's a great guy.


Second: I have not looked at any source code for any version of any operating system (though the code for the linux kernel is installed on my HD, yay).

Third: The overhead for all this magical "16-bit to 32-bit" switching is not noticeable for my version of Windows 98 at home, so even if it is true, it's certainly not crippling performance. I don't want to get into a linux/Unix/"Windoze!" flame-war, move those back to slashdot where they belong. Besides, EVERYONE knows that the BeOS is the wave of the future! EVERYONE.

Fourth: getting back to the original question, did you know you don't have to physically copy and paste in Access? You can use a button that says "copy info to next textbox" instead. Don't use the clipboard as it is something you can't control as easily as a command button or some other procedure (maybe just automatically copy the text to the second textbox?).


--Pete

Flames may be directed to cmdrtaco@slashdot.org, I don't want to hear any of them.

--
Find common answers using Google Groups:

http://groups.google.com/groups?group=comp.databases.ms-access

Corrupt MDBs FAQ

http://www.granite.ab.ca/access/corruptmdbs.htm