The problem
Although one might assume this is a de rigeur problem with a mismanaged workbook, please hear me out. I'm working with a relatively modest (80-100kb) excel file. It has minimal formatting, very few formulas, and it's vba code doesn't do anything too fancy. I've been working with vba for a few months now and have had this problem exactly once before. As this tool will be used in producing reports for a while to come, and as I've limited time, I'd rather not rebuild the whole thing or turn in an unwieldy project.
Details
My code loops through several dozen 200+kb .xls files using Workbooks.Open method and grabs 1-2 values depending on what it's opened. It's been working through over a half dozen iterations with no change in size. In my latest version it's balloned from 100kb to 10mb. No tabs have been added, I've looked extensively for all sorts of formatting and other traditional pitfalls—it's not my first rodeo in that respect. I am new-ish to vba though, and so often step through code and have to pause or stop debugging before resuming to correct syntax. Sometimes this will happen before any Workbooks.Close method.
I think, inexplicably, during some combination of saves/crashes/debugging, excel has 'saved' some of the opened workbooks in this file's memory. It gets weirder: if I copy all of my worksheets, as well as my code, to a new workbook, the file size falls back down to 100kb or so. I've had this problem once before. Using a 20kb workbook I was trying to pull values from a 135mb workbook; after one save I noticed that my workbook was now 135mb and change, and I was only able to get it back down to 20kb by copying everything one sheet at a time to a new workbook. Does anyone know what's going on?
Attempting to google this produces dozens of pages on extraneous formatting, formulas, and VBA code unrelated to my issue.
I could post pseudo-code if it would be useful to see, but I'm pretty sure it wouldn't be too enlightening, and that my problem is some memory issue that occurs between .Open and .Close methods.
Edit: after looking through some of the workbooks that I'm opening, quite a few of them are 'around' 10mb. It seems suspicious to me that my tool would increase in size by about as much as one of the .xlsx files I'm opening.
Related
My personal workbook (PERSONAL.xlsm) has stopped allowing me to view the code or any details of the modules I have saved there. It also will not allow me to run any of the Macros it once included. I don't know if they got deleted or are hiding somewhere (but I am hoping it is the later). I have not done anything out of the ordinary. Before this issue was happening all I had done with excel today was run one of these macros (without issue), make an edit to include the solver in a macro, and save it.
In addition to this problem there are a few others that seem to accompany it:
Occasionally when I close excel without saving a file, excel crashes.
If I attempt to record a macro (either in the Personal Workbook or to
another location) one of the following happens:
a. Excel crashes.
b. Excel gives me an Invalid Name Error (despite the name being perfectly valid.
It is worth noting that macros not saved in the Personal Workbook work just fine. I am very stumped and cannot find a solution to this problem anywhere. I have tried the obvious (rebooting my computer), the not so obvious (restoring previous versions of files), and the weird (disabling and enabling random things in the excel options section). Please, if you have a solution let me know!
Thank you in advance, all and any suggestions are appreciated!
I had a similar problem a while ago. I had to:
close Excel
re-name PERSONAL.xlsm to something else (like temp.xlsm)
open Excel and verify it does not "see" or attempt to open PERSONAL
create a new PERSONAL.xlsm
copy all VBA from temp.xlsm to the new PERSONAL.xlsm
Can't comment yet, so i apologize in advance.
It is definitely Excel at fault, it happens to me so often (on big files including VBA) that my before_save saves a copy of the file with time in its name, and all module's, userform's, sheet's code as *.frm, *.cls, *.bas.
I usually can also open corrupt files by holding SHIFT key (force designer mode) and then copy manually stuff.
I have a large userform in a project that is causing some issues when it is loaded into memory. There isn't anything exotic happening in the Userform_Initialize event (just populating combo boxes and setting default properties).
Everything was working just fine a few weeks ago when the userform wasn't as big (measured in KB). Initially, I thought the workbook was corrupted and proceeded to export every userform, module and class, re-import into a new workbook, and subsequently compiling the project as I've always done. This did not fix the issue. Interestingly enough, when I put a Stop at the top of the initialize event, and step through the code, everything works fine.
Main Idea
This got me thinking that the possible cause of the issue is the fact that the userform is very large, thus the process of loading the userform into memory is taking longer than the typical load. Essentially, the vb editor is continuing to execute the code in the initialize event, attempting to access controls that may not be in memory yet.
I have done some crude analysis to get a pretty good idea of just how large the userform in question is. The userform was exported and re-imported into a blank workbook. The workbook without the userform was around 30 KB, and with the userform, the workbook was over 350 KB, so we can conclude that the userform is around 320 KB.
It is important to note that I have extensive error handling in my project, however, I'm unable to identify this particular error as it is occurring in the initialize event (Error handling is impossible inside this particular event [Bovey, Professional Excel Development, pg 489]).
Question : With the exception of a time delay (e.g. Application.Wait or Sleep via Windows API), is there another approach to avoid crashing?
UPDATE
It turns out that delaying the application didn't work reliably either. I have actually removed the entire Initialize event to no avail as well. One thing that I forgot to mention in my original post, was that I was abusing the Debug -->> Compile VBA Project feature. See my answer below.
After dealing with this for quite some time, a colleague of mine simply commented one random line of code (not in the UserForm_Initialize, just in some random module), saved the file, and reopened it with no issues. We then discovered that the issue was not in the code, but rather with Debug -->> Compile VBA Project. For the most part, I use Debug -->> Compile VBA Project, about once every hour as I'm coding. I then save that file and continue developing on that very same compiled file. When it is all said and done, I probably run Debug -->> Compile VBA Project about 100 times over the course of two weeks. I then found this comment from Chip Pearson on this website:
VBA code is never stored as the plain text that you type in to the
editor. Input is immediately converted to platform- and
version-independent byte codes called OpCodes. These OpCodes are
converted by the editor to the text you see on the screen. When you
compile the project, the compiler translates these OpCodes to
platform- and version-specific codes called ExCodes. When you run the
code, the runtime reads the ExCodes and executes actual machine code
on behalf of the project based on the ExCodes. This whole process is
similar in principle to how Java and the Java Virtual Machine work.
If you were to export all your VBA code to text files and then remove
all the modules and then re-import the code from the text files back
into VBA (which is exactly what Rob Bovey's Code Cleaner does), you'll
see a decrease in file size. This is because the ExCodes were purged
and have not yet been recreated. Then, if you compile the project, the
file size will increase because now it stores the ExCodes in addition
to the OpCodes.
You really never need to compile the code. VBA will automatically do
it when necessary. However, the Compile command also does syntax
checking, which is its only real practical purpose.
And this is from Rob Bovey himself found here (You will also find Rob Bovey's Code Cleaner at that website):
During the process of creating VBA programs a lot of junk code builds up in your files. If you don't clean your files periodically you will begin to experience strange problems caused by this extra baggage. Cleaning a project involves exporting the contents of all its VBComponents to text files, deleting the components and then importing the components back from the text files.
I then did just as I did above in the original question. I exported all modules, re-imported them into a fresh excel workbook, added the relevant libraries, and DID NOT (as I was before) run Debug -->> Compile VBA Project. I haven't had any issues since.
I'm writing a VBA code that will run everything after I leave the office.
The macro works fine, the problems is that sometimes (more often than I'd like) I get the message:
Excel cannot complete this task with the available resources. Choose less data or close other applications. Excel cannot complete this task with the available resources. Choose less data or close other applications. Continue without Undo?
I just click OK and the code runs fine, but I have do click the OK manually,
I've already tried the
Application.DisplayAlerts = False
but this doesn't work.
Does anyone know if I can't make excel "overpass" this problem?
Thank you in advanced
I believe "Continue without Undo" means Excel is temporarily clearing the RAM it uses to track undo levels and then (it seems) your macro has the resources it needs to complete the process.
Take a look at what your macro is doing to use so much RAM: Is there a way to modify it so that less RAM is required? There are several options for this listed here:
How to clear memory to prevent "out of memory error" in excel vba?
Second option to fix this might be adding RAM to your machine, but it will not fix the cause of the error.
Third, if you want to risk a registry edit and reduced or eliminated undo levels in Excel, you might be able to prevent this error by reducing the number of undo levels (http://support.microsoft.com/kb/211922).
It could be cumbersome at times to maitain Excel Workbook's formatting/settings when heavy backend, front end work loads are done. At times (even frequently) workbooks were crashed. But I can't recall what the code or process was to avoid this happening due to the formatting. What I am clear is that before any data retrieval, processing took place in the workbook, I saved the Workbook's formatting/settings into an object. Once everything was completed, that object was called to restore. It was most probably one of the custom/user written classes.
That code was very handy when working with Workbooks to manage certain company standards/Logos/Colour Pallete/formatting/protection settings/code settings and so on.
So I just want to ask if anyone in the community have come across such process? I searched online and disappointing enough I am unable to find anything near - else I have really lost my wits on key-word search ;)
PS: This is not my home work or work. So please throw some light.
If you are talking about creating spreadsheets that conform to your branding standards, why don't you just create a template file:
http://office.microsoft.com/en-us/excel-help/save-a-workbook-or-worksheet-as-a-template-HA010218874.aspx
During the development of some Excel vba code, in about every other iteration where I go in, add some code and then save the file, the next time I open it, I get a "File not Found" error. The macro is set to automatically run the code upon opening the file.
To fix it, I copied all the code - modules and classes plus the startup code - to a fresh blank excel file. I save the excel macro file and it runs fine.
This happens for both Excel 2003 and 2007. What is happening here?
My psycho powers tell me you are relying on relative paths while changing the current directory.
I'm seeing a similar phenomenon, though I'm not sure the cause is the same.
Yesterday, every time I added a Workbook_Open procedure to my workbook, saved it and reopened it, I got the "File not found" error (no particular file specified). followed by "We found a problem with some content in [workbook name]. Do you want us to try to recover as much as we can?". If I said Yes to recovering, I found that all the VBA code was gone from the workbook.
It turned out that this was caused by my virus checker (BitDefender), which considered my code to be malware and was removing code from the workbook. I tried it on a PC with a different virus checker (BullGuard) and it did something similar. At least BullGuard had the decency to tell me it was modifying my file. BitDefender didn't give me any clue at all!
On a general point, as someone who does VBA work for many different clients, I'm finding more and more problems with virus checkers getting in my way.
Not sure if you have solved your problem.
One possibility is that one of your module is too long.
VBA is a compiled size limit for 64kb. It is "supposed" to warn you if you exceed that, but often it fails.
Find out the longest Module that you have, move some function out to another module and see if it helps.
I have this often.