Like suppose, your .xlsm file is about more than 5 mb
It has more than 20 sub procedures any many more. Many inbuilt formulas & functions are used in the background on the excel sheet. Yes, more than 20 Excel sheets. So this is how large Excel VBA Application looks like.
Now, I found one issue with the large application, It stops working or freezes or not respond when your application is open in your system for more than few hrs without having any action on it!
Yes, and as soon as you activate your workbook after a long hr of other work, workbook almost freezes or showing not responding. and we need to close the excel file anyhow for further any process.
It's very common encounters who has worked on large excel files. Please discuss here the reasons, causes, and solutions.
Related
I have developed on my Mac, a small (5 worksheets and ~230Ko) workbook that contains many VBA macros.
When I use this same workbook on other mac computers (I have tested like 4 with different OS and faster hardware specs) saving/closing the workbook takes like >30 seconds when it is lightening fast on my old mac that I used to create the xls.
This saving time is a no-go for me.
We tried to check the excel options... they appeared to be the same.
What can I do to diagnose what the difference is, and to fix this issue ?
A friend of mine solved it.
For future reference:
Quit excel
in Library/Settings (translated from french YMMV), find and delete com.microsoft.excel.plist
Restart
I've seen other users post somewhat the same question, but the core problem doesn't seem to be the same (as far as I can tell).
I have an Excel workbook that goes through about 80 000 rows and four columns of data. This takes about 1-2 seconds at the most. The workbook does do operations in other worksheets but for the test I have turned those subs off. If I open an .xlsx of about 10 Mb it takes a bit longer but not much. If I open up an .xlsm with some considerable code, it takes about 6-7 seconds to do the same thing.
What I have read so far is that one should use set variables of ranges instead of cell references, calculation set to manual, screenupdating off. None of these seem to do the trick though.
If the events were not disabled, this could also be added just before the code begins:
Application.EnableEvents = False
Changing it to True when everything is finished.
If you wish to optimize things further, one possibility is to assign it to a variable:
Dim Temp as Variant
Temp = ActiveSheet.UsedRange.Value
Analyze and change Temp, and then put it back
ActiveSheet.UsedRange = Temp
I finally figured it out. It has to do with instances of Excel. If multiple heavy macro files are opened in the same instance of Excel it takes a lot longer than if one instance per file is used. I don't know why this is, but from what I've read it's a bug that's been around since Office 2003 or something.
So now all I have to do is make sure that everyone uses multiple instances. Unfortunately you have to do some register changes to make that happen automatically. I'm currently going with the .bat file alternative.
I am using Excel 2007 (32Bit) on a Windows 7 64Bit machine.
I have a large Workbook with 12 sheets and 18 VBA modules.
All of my subroutines run flawlessly but one is causing the following issue:
The macro itself runs from start to finish successfully just as specified. After running the macro successfully, the workbook crashes, when I try to save it. It also crashes when AutoSave tries to save the workbook. The workbook does not crash when I simply close it.
By crashing, I mean that I get the message "Microsoft Office Excel has stopped working".
In the Windows Event Viewer I have identified the error message 0xc0000005.
In the folder where the workbook is saved, I find the temporary files that Excel creates when saving a workbook (named something like 9BB7B000).
I have tried to repair Excel in the Programs and Features part of the Control Panel but it has not worked. Furthermore no Add-Ins are enabled.
I suspected that the code module of the problem-causing macro was too large (90KB) so I split it up into two modules smaller than 64KB. However, the problem remains.
I would appreciate any help on this issue. I would like to get around reconstructing the workbook manually, if possible, as that would mean an enormous effort.
Thank you very much in advance.
Jochen
I had the same issue some time ago and carried out a research to identify the issue to no avail.
I noticed that it worked fine on workstations with better procs and more ram.
However the only way for me to proceed was to create a new workbook a one-by-one copy each worksheet from the old workbook and see which one is causing the issue. If the macro is causing the error then try to add a "sleep" command between loops so that the Excel file regains control and can execute and awaiting events/commands.
The post was 9 months ago, could you fix it?
What does that specific macro do? Because there are several solutions to this problem.
It seems that a certain "action" in your macro takes too long.
You can search for that specific action and us application.wait to slow your macro down. If this doesn't work, you'll have to find a way to reduce the "workload". But to do that, i'll need to take a look at your code.
Turn off the AutoSave function in Excel Options
I am not sure if this can be done, but it would be great if the user can use the excel spreadsheet while the macro is running at the backend. Is there any way this can be done? Thanks.
EDIT: The user is repeatedly (>10^5 times) generating Random permutations on n items (n ~ 100) through a macro. This might take around 10-15 mins (or more) to get done. So, if the user can open the excel workbook to do other tasks, while the macro is running , it would be nice. (It would typically be a different workbook from the one in which macro is running). Please let me know if this can be done and if yes, any performance effects that it might have on the macro which is running. Thanks.
The user can open a second instance of the Excel application while the macro is running and work as normal on other workbooks. The same workbook can also be opened but as read only.
I'm working on some VBA heavy sheets in Excel 2007. At my previous work we had a lot of sheets which were calc-ing for a long period ( valuing trades etc ) and if you opened another 2003 session completely they didn't interfere with each other.
It seems in 2007 if one Excel session is running and is working hard on VBA then other Excel sessions also hang. It's most annoying as I can't even code in the VBE while the other runs.
Has anyone else noticed this? I am on an 8 CPU workstation and it is nowhere near flat out. The only thing I can think of is that they do both load the same .xla's on start up but I would have thought each xla would be inside the seperate Excel sessions?
No matter how many Excel workbooks (of one version) you open, they all still operate off of the same process. If one workbook demands all of the resources of that process, then all of the workbooks will suffer the same lag.
Different versions of Excel, however, will not interfere with each other. If you're running both versions, you could relegate one version to a specific task and then use the other. It is also possible in 2003 (and perhaps 2007) to spawn different instances of the actual application by starting Excel from the Start menu while Excel is already open, but that's known to cause errors, especially if you utilize a personal workbook to store macros or other data. If both 2003 and 2007 are trying to open the same personal workbook, you'll wind up with the same issue.