I had a "Compile Error: Can't find project or library" error when opening a database that I have programmed on a new workstation (that I do not typically use).
The really odd thing is that the highlighted code is LCase which is something extremely basic. That the reference for this could be missing in even a freshly installed standard edition of MS Access is unlikely.
Having googled this phenomenon I have read that sometimes Excel Files don't grab all necessary refrences when they are copied. Chip Pearson's excellent article explains which references are needed.
So I tried to go check if all references are available, when stranger still, I couldn't even access the Tools>References in Access because it was grayed out.
Why would this happen and how can I fix it?
Any advice or hints on how to investigate this are appreciated.
VBA references are not available for viewing or editing in an .mde or .accde Access database. It must be a .mdb or .accdb to view references.
Sometimes things move quicker than expected. Upon searching yet another time, I found the solution to the problem.
In needed to add VBA infront of UCase, LCase, or Space . Apparently on some machines linking to compiled DLL files causes this problem.
VBA.LCase, etc. solves it.
I have a two broken VIs with front panels that open fine, but I can't edit or run them, or open theis block diagrams.
One of these was made as a replacement for the first when it started to have this problem. I need to at least find out how to avoid this problem in future, so I don't lose work on bigger VIs.
I'm not sure if it makes any difference, but I very recently upgraded to LabVIEW 2013.
Thank you in advance.
This is the error I get when I try to run them:
"
VI has a bad connection to or cannot find a subVI or external routine.
This VI has a bad connection to or cannot find a subVI or external routine but
it has no block diagram to show or fix the error. You must find or correct the
subVI or external routine. Check for more information in the Explain dialog box
in Get Info.
"
Before reverting to a previous version (using dropbox) I got a different error with one of them:
"
LabVIEW: Generic error.
An error occurred loading VI 'sweep harmonics first test.vi', LabVIEW load
error code 6: Could not load the block diagram.
"
One situation how this happened.
Sometime LabVIEW crashes, and it restart. After restart, LabVIEW will ask you to recover the autosaved code.
I personally always discard those autosaved code. If you do choose to recover autosaved code, there is a chance the recovered code is corrupted. Once you save corrupted code to disk, you are probably going to lose the ability to open/save the block diagram ever again.
Having a version control system is usually a way to avoid minimize the damage when LabVIEW crashes. At worst, you loose maybe an hour worth of work.
If you can't open Block Diagram of your VI, first check the suggestion by #Rodrigo - it is most likely just a "compiled" VI, which has Block Diagram removed.
If you think there is Block Diagram inside and it is just corruped - you may contact NI support. And if you want to look deeper by yourself, extract the VI to XML using pyLabview, and look into the XML - there you can modify every single part of the VI. For example, you may start removing parts until it starts working.
I wouldn't go into manual VI editing unless you have at least a dozen of affected files though. For a single file, it will be faster to re-create it in LabVIEW instead of trying to understand the internals. If many files are affected - may be worth finding the issue in one, as other files probably have the same glitch, so you can make a script which extracts, modifies and re-creates VIs automatically.
From the sound of it, I believe what happens is that you are trying to run the VI's created as "DATA" for an executable, instead of the actual source VI's.
When you build an executable LabVIEW creates a copy of all the Top Level VI's dependencies into the support (DATA) folder which should be in the same directory as your executable.
Try opening the VI's that are marked as not having a block diagram and navigate to File>>VI Properties to check the path from which the VI is being loaded. If it's not the original VI, you can just replace it.
Having a very odd issue with Visual Studio 2013, curious if anyone else is seeing anything similar. I have VS 2013 Ultimate, it seems like once a day, while I'm working with a file, the compiler just suddenly freaks out and doesn't detect my code anymore in my web forms. Take a look at the screenshot below (I just chose a random spot in the middle of the web form), but out of nowhere, VS starts erroring, telling me that variables aren't declared, that method arguments need parenthesis on lines of code that aren't methods, all sorts of whacky stuff.
I assure you, I don't have any broken references, I didn't forget to close an if statement.. nothing like that. All I'm doing it writing some code, and randomly the whole page just starts to error like this. To resolve, all I can do is copy the code contents, delete the page, recreate the page, and paste the contents back into my "new" file... same exact code, only no errors. I wouldn't even worry about doing this if I wasn't doing this at least once a day.
Any help is appreciated, thanks!
Edit: For what it's worth, I found a slightly easier workaround for this issue. If I edit the properties of the class file to "Do not Compile" and then back to "Compile", the IDE is able to read the file just fine...
It looks like this is simply a bug in the Vb.Net Compiler / IDE. I agree it's unlikely to be a bug in your code because you can see that the error squiggles don't line up with places that would represent the errors you are reporting. This is sometimes a sign of an IDE bug
In terms of fixing the problem though you can probably get them to go away by closing and reopening the solution in question. Baring that restarting Visual Studio. I wouldn't resort to deleted / recreating the page.
Long term though you may want to file an issue on connect so the IDE team can try and fix the problem.
http://connect.microsoft.com/VisualStudio
I have been writing VBA code for a split database, and as of late, some of the command buttons will close the instance of access on the end users machine. No warnings, no ability to stop it from happening. If I add a breakpoint, the code doesnt even hit the click event, it just closes out entirely. This however, is briefly solved by adding a NEW command button and then transferring the code over. What gives?
Repairing and compacting a database rarely seems to solve database corruption problems, and neither does decompiling it (although these can work).
I'd follow these steps (as per Dan's suggestion):
create a new database
import all objects (tables, queries, forms, reports, macros and modules) from old database
At this point it may hang on one particular form or report. If this happens, just omit this form/report from the import (although you may well be unable ever to get at it again!).
Finally, compile any VBA code, repair any references to other VBA object libraries, redraw your relationships window so it looks as pretty as it did before (the relationships themselves aren't lost; just the way they're arranged) - and curse Access!
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