I developed a small application which accesses a MS access database on my computer using VB.net. I developed the program on windows xp 32 bit. At the moment I am using windows 7 64 bit and the program simply will not run. I get a null reference exception when I try to do anything to the database. I have narrowed this down i THINK to the db provider. I was using Provider=Microsoft.Jet.OLEDB.4.0; and tried using Provider=Microsoft.ACE.OLEDB.12.0;. Neither seems to work. The path to my database is 100% correct. This is the error I am getting:
Null reference exception was unhandled.
Object reference not set to an instance of an object.
Like I say the program runs fine on the windows xp machine. If it helps the access database file extension is mdb.
No DLL exist for 64 bit access to Access database files so you must go to the project properties and on the "Compile" tab go to "Advanced Compile Options" and set "Target CPU" to "x86" I hope this helps.
I was having the exact same problem, except writing to a SQL 2008 DB. VS2008, VB.net code with framework 3.5, Windows 7 64-bit. Code runs fine on XP.
John R's answer provided the right solution: changing the project's advanced compile options to set "Target CPU" to "x86".
This problem can have more symptoms than originally described. I'll generalize them:
Accessing ACCESS isn't the only problem; it happens with SQL (at least MS SQL 2008) too.
Some of the DB calls can and do work. It's as if the calls set you up for failure, but the point of failure happens later, at a random point in your program.
The point of failure I saw was during a subroutine call. (just a normal call to a subroutine I created in VB.) Putting a try-catch block around the call wouldn't catch the error though.
Here's the strangest part: Previous to the errant subroutine call, the code had a HANDLED exception. Ironically, the exception was EXACTLY what was being thrown at the errant call. When I "tweaked" the code to avoid the prior exception, NO exception was thrown at the errant call; the VB program JUST QUIT WITH NO ERROR! It appears that whatever code is having the problem, it is reusing the last handled exception. This would mean that if your code previously had an "index out of bounds" or "divide by 0" error, this is what you'd (probably) see when the code barfs (because of no 64-bit dll.) So this problem can masquerade as a whole bunch of errors!
Doesn't sound like a Provider error because the Jet part is fine. Make sure your Data Source path is correct. If you have it in your Projects folder on VS and are using a full path it may need to change because of how the file system is set up with Users vs Documents and Settings.
Related
I have written a rather complex application in Microsoft Access. It is split into front end and back end files. To protect my code, I have compiled it and saved it as a runtime .accde file, which I then changed to an .accdr file to ensure it operated as a runtime. I have created two versions of the application: one for those with 32-bit Office installed and one for those with 64-bit office. I have used Inno Setup to package the application, the data file, and other files such as the icon file, the license file, etc., into an installable package, which works just fine.
Among my team of 27 beta testers of this application, so far 6 have downloaded it, and I have tested it on four of my own computers. On seven of these computers, the installation works perfectly and the application runs with no problems.
On the computers of three of my testers, when they try to run it, they get this error message:
The expression On Open you entered as the event property setting produced the following error: Bad file name or number.
* The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].
I'm pretty sure I know where the code is that's causing the problem, but cannot for the life of me figure out why the application crashes on those 2 computers but not on others.
The On Open event I suspect of causing the problem checks the linked tables, gets their connect string, then looks at the path for that string for the back end database. If it does not find it there, the procedure pops up a file selector dialog and instructs the user to find the data file, then it relinks all the tables.
If anyone could point me in the right direction to fixing this problem, I would be extremely grateful.
This is typically caused by a reference labelled as MISSING.
You have two (three) options:
Run the application on the offending machines with a full version of Access that lets you debug the code
Create a small test application that lists and verifies the references you use, and run this on the offending machines
Remove those two customers
Thanks to all the contributors here. Because of these folks and additional online research, the latest answer I can find is this:
This error occurs on a small percentage of computers on which the app is installed, and no one has yet figured out why, what causes it, or how to fix it. The workaround is to install the 2013 version of the Access runtime, as later versions will still cause the problem.
At least one of the offending computers is running the Click-to-Run version of Office. Still gathering information, but that's the status as of now.
I have an Excel addin, developed in VBA, deployed on the network.
The addin reads from an Oracle database, and pastes tables in a new worksheet, which will also contain a button (triangle shape) to refresh the table.
Everything works great, but I must protect code with password.
When i do, the following error appears on some machines:
Compile error in hidden module: Main.
This error commonly occurs when code is incompatible with the version, platform, or architecture of this application.
Although it compiles perfectly when unlocked.
On other machines it requires VBA password on close, even though i have nothing of the sort defined under close event.
I am hoping to secure my code, without running into above problems.
Any suggestions are appreciated.
I know of two situations in which this error occurs:
1: 32bit vs. 64bit issues (already mentioned in the comments). If you've developed a 32bit addin and try to deploy/use it within a 64bit Excel, then your quoted error message will appear.
2: Missing references.
I think the second option is more likely to be the cause of the problem, because usually all client PCs in a company will have the identical version of MS Office installed and this error occurs only on some machines.
So I suggest to check your references. In the VBA-Editor (Alt+F11) go to tools --> references and note down any ticked modules. Then compare this to a client where the error is occuring (go to client PC and repeat the procedure).
If the ticked modules don't match between development and client PC, this is most likely the cause of this issue. You might also encounter modules with a "MISSING" written in front of their name on the client PC. In this case, remove the tick from the missing module and try to execute your addin.
If it works flawlessly you should be good to go, if not you'll have to manually install the missing modules on the clients PC.
Hope this will help you.
I am trying to create a word document using visual basic. I have found that this can be done using the Microsoft.Office.Interop.Word objects.
I have found some tutorials online (https://support.microsoft.com/en-us/kb/316384) about how to create a word document programmatically.
I have created a simple windows form application. When a button is clicked the word document will be created. I made sure to add the reference to Microsoft.Office.Interop.Word in my application.
My problem is that an error keeps getting thrown at this point:
app = New Microsoft.Office.Interop.Word.Application
The error is:
COMException occurred
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.dll
Additional information: Retrieving the COM class factory for component with CLSID (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: ox80080005 (COE_SERVER EXEC FAILURE)).
I have read that the following needs to be done, so I have made sure that word 2013 is installed on my machine and I have set the target CPU to x64 inside the application's properties.
If anyone has any insight to what I am missing or if I am doing something wrong I would appreciate the help.
Update:
I have tested my code on another machine and it works. So the source of this error is not the code.
Update: Pt. 2
I've been doing some more research (http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=10010&EvtSrc=DCOM&LCID=1033) and I believe I may be getting closer to the source of the problem. I've gone into the registry and it seems that the local server it is failing to communicate with is pointing to WINWORD.exe which makes sense. What does not make sense is that it is looking for the wrong WINWORD.exe. I am going to try and fix this so it is pointing to the WINWORD.exe for Word 2013 instead of Word 2010.
Solution
What ended up fixing my problem was preforming a quick repair on office. I went to control panel, programs and features, selected office, pressed the change button, and selected quick repair. Do not know what caused things to get messed up, but this did fix my problem.
Where do you run the code? Is it a Windows service or ASP.NET application?
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
You may find existing threads with the same issue described:
System.Runtime.InteropServices.COMException (0x80080005): Retrieving the COM class factory for component with CLSID
Office Automation in .NET - COMException 80080005
Word Automation with ASP.NET
Finally, if all the mentioned information is not relevant to your case I'd suggest repairing Office. It looks like something is wrong with its windows registry keys.
Good morning.
I'm in the process of writing a vb.NET forms application that will read in a selection of .xlsX files and import their contents into a SQL2012 database. Because the files are in different folders and are all formatted differently, I'm having to write it so that each folder's contents is handled by its own dedicated module. However, one thing that's common across each folder is the process that I need to go through, which is to open each file, read its contents into a DataTable, carry out any manipulation required (i.e. removing empty rows) and then run a SqlBulkCopy to load the data into SQL before moving the original file into an archive location.
So far, so good. I've written and successfully run three of these modules, but the fourth one is giving me the error that's detailed in the Title of this post - the exception is thrown at the point where I'm trying to open the connection string to the Excel object. Again I stress that I've done this three times before, and each time has been successful.
Also, I've noticed that the exception only occurs when running the code in Debug mode. If I run it in Release mode it works without any complaints.
I'm developing this application in a 64-bit environment (VS2010 on Windows 8.1), but targeting the application to x86. I'm happy to continue writing in Release rather than Debug mode, but I'm curious as to why it works in one but not the other and I'd like to be able to code for both modes if at all possible.
TIA
I'm experiencing a weird behavior from a DLL function I have written to access an Oracle DB via Pro*C; specifically, it works fine when I call it from MQL4, and instead crashes at a specific line when called from a C client.
Crash reason says "Unhandled exception at 0x61428C74 (oranls11.dll) in GAClient.exe: 0xC0000005: Access violation writing location 0x00E368EC."
I'm using Visual Studio 2010 on Windows 8 64bit, though the development environment is set to build 32-bit DLL.
After several days debugging, I have reached the following conclusions:
- The crash occurs when EXEC SQL FETCH is called. Cursor opens fine.
- All parameters passed to the DLL function reach the crash point with exactly the same values, as I could gather from a series of fprintf() commands. This is also (and especially) true for the variable used to fetch into.
- Oracle Session Trace files are virtually identical, apparently showing Fetch, too, was successful
- Both clients (MT4.exe and GAClient.exe) are executed from command prompt, with the same set of environment variables (PATH, ORACLE_HOME, etc.)
I'm not even sure which code fragments would be useful to post at this stage; if someone has any idea where to start fixing this, I'd be more than happy to share.