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
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 a desktop Windows Forms application I built.
As we try out improvements to the program, I make the changes on a test version of the application, which connects to a test copy of the Microsoft SQL database on the back end.
Basically, to start out, I just copied the program to a different directory, re-named the assembly, created a different PublicTokenKey and used that.
The problem is when I try to run a the test copy and the live copy at the same time. It pretty clearly thinks they are the same program (when I click on the second one, the "busy" circle simple turns for a second, then the already-opened icon in the taksbar gets highlighted), even though they show up in the Task Manager as differently named applications.
What do I need to tweak in Visual Studio so Windows 10 will recognize them as different, separate programs?
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.
I came by this page and was thinking about the best method to distribute my VbaProject.OTM file (located into %appdata%\Microsoft\Outlook\) to a bunch of ~30 users at my office. Is it better to simply copy/paste the OTM file onto the network and then copy/paste it back to all users' computers (manually or with a .bat) OR would it be better to use the method described in the link above to generate a OPS file and import it back with Proflwiz.exe? What's the difference?
We are all on Microsoft Office Outlook 2003 actually, we might upgrade to 2007 one day but still years from now.
Finally came up with some elements to deploy a Outlook VBA Project. There are a lot of ways to do this, but the easiest way to do so without installing anything and keeping the same methodology would be to run a OTM file directly from a server. I found out that the process outlook.exe has a parameter altvba that allows to specify another path to run the OTM file from. Here is en example:
outlook.exe /altvba "\\myServer\myFolder\myFile.otm"
This allows me to update only one file to get all computers updated. Obviously, if the file is big and the server's ping is on the high side, it may delay the launch of Outlook. The other problem with this method is that everybody will have to shut down Office if you want to update the OTM file on the server (and if you do work in an office where everyone uses Outlook, you do know that it is impossible to get everyone to shut it down at the same time, except if you code a macro to do so eventually). To prevent both those problems, I could setup a batch file to copy the server OTM file clientside everytime there is a new version (just have to check the NTFS last-modify attribute). This way, Outlook will boot with a local file, the batch file take 2-3 seconds to copy the file if needed (or will launch Outlook instantaneously) and there will be no problem updating the OTM file on the server. Users will have to start Outlook with the batch file (or with the slightly different outlook.exe path with the altvba parameter, so either way they need a different shortcut/file to start off the first time). One other advantage of the altvba is that it's still easy for the user to run Outlook without it (to see if the VBA is problematic or not in case Outlook is sluggish) and the file will remain unchanged after a Outlook reinitialization.
Others solutions include a COM complement that can be developed in a lot on languages including VB6 (no conversion needed from VBA). There is also a bunch of tools included into Microsoft Office XP Developer that could help getting the job done (not free however, especially if you need the most up-to-date version).
This is a weird persistant issue I am having with a small visual basic program.
Problem: The excutable of the vb program crashes when trying to run but when I step through the program inside of visual studio it runs successfully.
Details: The program performs a winscp.com transfer from a ftp server and then takes the downloaded file and extracts the data from it before sending it to a webpage. The program also decrypts a des3 encrypted file which holds the login details for the sftp server and the webpage.
My Thoughts: I was thinking this could be something to do with the excutable jumping ahead of the slower transfer and decrypt functions thus causing a "file not found" exception to be produced and the program to exit. Lending to this if I slowly (aka spend 10+ seconds stepping through the code) move through the code it works just fine.
Solution: I was thinking of including some kind of checks inside the program to make sure that the file exsists before moving on but I still wanted to get your guys opinion.
Thanks!
As requested
Crash Messages:
(I capture everything in exceptions and exit properly so no "crash" is reported but the error I get in my logs is as follows:)
1st run with standard test case:
Could not find file 'C:\Users\Administrator\Desktop..\ILC2INFOENC.txt'
2nd run standard case (the file above was not deleted by my cleanup function either as it could not be found)
Could not find file 'C:\Users\Administrator\Desktop..\ILCNETSL10663.csv'
Background:
The first file that is found missing is the encrypted login information file while the second file is the winscp.com downloaded csv file.
Thanks again for all the help and suggestions.
Solution: Applied checks to the existance of the files in question as to keep the vb program from jumping ahead of the slower moning openssl decrypt and the winscp file transfer. If I had the time to redo this portion of code I would have utilized the .net framework provided sftp function and the decrypter instead of winscp and openssl as to better control the flow of the program! If you need more options check below the original question for different takes of this issue.