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 have exactly the problem described here:
From what I can see on the web, this is a fairly common complaint, but answers seem to be rarer. The problem is this:
We have a number of Excel VBA apps which work perfectly on a number of users' machines. However on one machine they stop on certain lines of code. It is always the same lines, but those lines seem to have nothing in common with one another.
If you press F5 (run) after the halt, the app continues, so it's almost like a break point has been added. We've tried selecting 'remove all breaks' from the menu and even adding a break and removing it again.
We've had this issue with single apps before and we've 'bodged' it by cutting code out of modules, compiling and then pasting it back in etc.
The problem now seems to relate to Excel itself rather than a single .xls, so we're a little unsure how to manage this.
I have managed to resolve it with the accepted answer, but now, when I send the VBA file to my colleagues, they have the same problem.
My question and my problem is - any ideas what to do, as far as it is really not a good idea to go to everyone and to debug every time. And I somehow do not want to add Application.EnableCancelKey = xlDisabled to my macros.
Sounds like a ghost break. File saved one time with a break in there. What has worked for me in the past was to remove any breaks you see and manually step through the code (F8) through completion and then save file. Prob now necessay to step all the way through but I like to know I went all the way and didn't miss any.
As of yesterday, I had a working macro that generated histograms using analysis toolpak (VBA). As you can see below, the analysis toolpak VBA add in is enabled, and I have set a reference in VBA.
The file is saved as .xlsm (macro enabled) and I can produce histograms without a macro:
But if I record a macro to make a histogram, I get this same error. This is happening for all functions within the analysis toolpak. What happened here?
... I'm going to have to call this one solved. Very VERY strange error that must be related to this
error message I received when I disabled both the analysis toolpak and the analysis toolpak for VBA add-ins. My code is back in working order after disabling/re-enabling these add-ins. Maybe someone knows exactly why this is happening, but I have to guess that add-ins are handled as hidden workbooks with VBA functions and something strange happened to that workbook. No clue.
my issue was that when I run the macro (to create a histogram), the first time, it runs normally but when rerun it, it gets the error, mentioned above.
I solved it by unchecking atpvbaen.xls from the references.
I'm working on a big Access 2003 project with Microsoft Access 2007. Recently, some users have started to experience problems with the buttons in my forms. For example, without any specific reason, clicking on a button or trying to execute any code will return the error:
File not found
There is no way to go into debug mode. When this happens the only thing to do is to restart the database. I tried adding the Stop command at the beginning of the executed block to try debugging it, but no code is executed at all. It's like a compilation error but it's only happening 5-10% of the time, which is really weird.
After some research, I found other people are having the same problem, for example this and this link. There are other examples too, with no real solutions yet.
My database can be okay for a week and then the problem starts to happen again. Half the time and users can't do much; they need to restart the database once or twice to get it back working, and after a few minutes the error might happen again.
Because this is Access 2007 and there are a lot of people experiencing this bug, I can't believe it isn't more documented.
What's the problem? Is the database somehow partially corrupted? What should I do? This is really annoying.
If I was in this situation one of the first things I would try would be to do a complete decompile+compact+recompile operation on the front-end database file, and then distribute that updated front-end out to the users to see if that improves things.
Detailed instructions on the decompile+compact+recompile steps are available here. Note: Be sure to read David W. Fenton's additional recommendations in his answer.
I had just experienced this for the first time. I had been making extensive coding changes in a form, and was required to reboot my PC without finishing debugging the code. When I opened the app, I immediately got the "file not found" message (it auto-starts a different form).
On a whim, I went to the form in question and commented out that entire module's code and the problem went away. After I went back in and uncommented that code, everything still worked as normal. I was able to continue debugging that code and lived for the rest of the day happily.
though this thread is over a year old I would like to share another very helpful observation.
This error "File not found:" may be caused by differing save behavior of Office versions and may not have anything to do with your code! In case of this error, try to open and save your troubled file in another Office version and it may work fine back in your main Office version.
Details:
Though programming VBA for years now, I had never had an unsolicited "File not found:" error. Weird also that the error message does not give a file name for the file not found. (Reminded me of another nasty error VBA sometimes shows on startup for no obious reason and erratically.) Luckily this error started after my first edits in PowerPoint 2010 after having tested the file in PowerPoint 2016. The error occurred when opening the .pptm but I had no startup procedure involving a file. So I've got the idea of some file in the .pptm zip archive not being found. Started to do a quick search on the internet and found only "shooting in the dark" suggestions. As I could start PowerPoint 2013 more easily (virtual machine) than PowerPoint 2016 (different Windows 10 boot partition), I tried to open the troubled file in PowerPoint 2013 and had no problems. I compiled the VBA project to check for error. Nothing. And save the file. After this re-saving in PowerPoint 2013, the file seems to work fine again in PowerPoint 2010 und did not show any problems after the first few edits, saves and re-opening. This being said, I wonder if PowerPoint 2016 saving is peculiar and if I can replicate/if I will run into the error again if saving the file again in PowerPoint 2016 and returning to PowerPoint 2010. (I'll make a note of this thread to add new insights once I worked with this file again in PowerPoint 2016.)
Hope this observation may spare many unnecessary un-/re-installations of Office and other desperate attempts.
Cheers!
A similar thing has just happened to me a couple of times with one of my .mdb front ends running in Access 2013, after the August 2019 update to Windows 10.
My DBs too have been through several versions of Access. On opening the database it says 'File Not Found' and throws up a public module (not one on which I have been working extensively recently), without opening the Autoexec (Switchboard) form. 'Debug, Compile' is possible and doesn't suggest any problem.
For me too, typing one space (or blank line or other character) anywhere in the code, and then deleting it, and saving, closing and re-opening seemed to provide a workaround, and all has been well for the last few days (I am the only user at present).
There is no one obvious module involved, although I will probably suspect the form module I have been working on most recently if the problem persists in a troublesome way.
Now, a few days later I have de-compiled, compacted and re-compiled the database, halving its size, so maybe that will have done the trick. I hope so.
I just had this problem. In my case, I think the issue is having a blank VBA module. I was moving procedures from one module to another and ended-up with a blank module. I couldn't delete the module manually and every time I tried to create a procedure to delete blank modules, I received the "File not found" error and the procedure I had just created was blanked out. I ended-up reverting to a backup.
The issue is just your references. One of the files for your references has been moved/deleted/updated. Remove and re-add your references to figure out which one.
I had a problem similar to this. A blank "File Not Found" error.
I turned off AutoCorrect and after clicking through several prompts/warnings which had me concerned, I then reopened the database and the error went away.
When reopening the database the problem was resolved.
I suspect this will fix many "File not found" errors which are probably related to the temporary link table losing a reference for whatever reason.
I had this same issue MS Excel.
On the user pressing a button a useless File Not Found error appeared.
I ran through all suggested above and no change or help.
COMPLETELY ACCIDENTALLY I removed a module that i use for updating the Application status. This also has some array storage within. However, on removing this module (and commenting out references to it within my code) it appears that the issue is now fixed across users.
One Issue, is I have the same Module name within several different deployment's of Excel Add-ins. I suspect that on first run Excel isn't able to automatically assume the difference between them.
I had noticed a WORK AROUND for the error in which you create a break point on the first line of code for the button in question and then resume on break - I assume that this helped Excel evaluate and namespace the modules as to not cause conflicts.
I had that problem and solved it this way: I eliminated the form where the vba code was and imported the same form from a backup file made before.
I found yet another solution (at least in my case): In trying to find the error, I tested the application I created on a co-workers computer. This somehow reset whatever went haywire in the file. Afterwards I was able to open up the file on my computer again and everything worked as it should!
EDIT: I have realized that the error, im my case, seems to have been connected in some way to my using SendKeys (see my attempt to automate a report here on SO).
Had the same problem. I stumbled on the fix by accident. For whatever reason, simply adding an on-click Event Procedure made everything better.
Open the form in design mode
Select an object on the form
Press F4 to display the object's properties
Event > On Click > dropdown > click [Event Procedure]
Then click the three dots, which will create a new event, and launch the Visual Basic editor. This will also add default code into the Visual Basic editor
Make no other changes
Save and close changes to the form
Restart the database
For what its worth, as I was wrestling with this issue, the error resolved itself in other ways, but none of them were repeatable.
I had this problem as well, and compact/repair did not fix it. In my case I had an old VBA module that was no longer used, and which referenced an object class that no longer existed. Removing the non-compiling code fixed the issue for me.
I have had this problem for many years now in access 2010. Always in the Autoexec form that opens on msaccess startup. I tried creating a very simple form that calls the original more complex form. To my surprise the more problem moved the the new simple form. By trial and error, I found that just editing the new simple Autoexec form the problem would go away, but turn up randomly months later ALWAYS after I had made programming changes elsewhere. Sometimes instead of the file not found error, I get just get a crash out of access - but the solution is the same procedure - make a small edit to the autoexec file (just add new blank line will do). My project has come through many versions of access (2000 -> 2010). If there was some way to automate the editing of my autoexec form, then restarting access - this would serve as a workaround. I have not found any way as yet.
I have had this problem for years in my access database. I tried all the above solutions an they all fixed the problem, only to have the problem reappear sometime later - always after VBA code change. I discovered that decompiling and then recompiling ALWAYS FIXES this problem, and is the quickest and easiest way to do so. So I have concluded that there is a bug in way Office only partly compiles after program changes like macros and VBA code changes. After a number of changes the system gets 'unhinged' and throws up the 'file not found' error. Reading thru the fixes users have found in this blog supports my theory. Nearly all these fixes would probably cause some sort and recompile the unhinged code.
MY SOLUTION
In summary I have found the following..
Doing a Decompile (without a recompile) will get rid of the error - but if the code is run on a different machine the error appears again.
Doing a decompile, then a recompile followed by a Compact and Repair results makes my app run on other machines with out any problems.
I had a class module - Class1 - that was not used. I deleted it and did a compact and repair.
Something happened that caused the name of the class module to stay in the Navigation Pane but the module as such was removed:
When opening the VBA editor I got the "File not found".
Impossible to delete the name from the Navigation Pane!!
When decompiling the project I got "An error occurred while loading 'Class1'. Do you want to continue loading the project?"
I did - now the Class1 was still in Navigation Pane when opening project again but now I could delete from the Navigation Pane.
After that the message about file not found no longer appeared.
FYI