pro*c dll fail when called from different clients - dll

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.

Related

Compiled Access Program Runs Fine on 7 Computers but Crashes on 3 others

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.

The specified procedure could not be found - how to identify?

I'm developing plugins for a program. Whenever I try to load my plugin in that program it crashes with an the specified procedure could not be foundbut nothing more.
Well to have an insight I tracked with Process Monitor (or ProcMon). I set the filter to just print messages for the process of my main program. However that application shows me including the libraries ends (after wandering through PATH) at the right file - i.e. Result: SUCCESS.
So my computer left me pretty clueless, yet refuses to work. Has anyone an idea how identify the missing procedure?
N.B.: Additionally I ran the DependencyWalker which gave me the usual error message because it's deprecated (dependency walker gives me errors on the system that runs correctly) - which could indicate that all dependencies are found.

VS2010 vb.NET: System.invalidOperationException: the 'Microsoft.ACE.OLEDB.12.0' provider is not registered at the local machine

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

Custom ifilter for sqlserver works only for first file

I created a custom ifilter for a new extension (.abc).
When I installed it in operative system, the search works well.
When I tried to use it in sqlserver 2012 on a full text index on a filetable table, I saw that only one file was indexed correctly.
I tried to debug the indexing task attaching the debug at fdhost.exe. I saw that my class was instantiated and destroyed exactly as many times as the files .abc in the table, but only the first time I saw calls to IPersistFile::Load, IFilter::Init, IFilter:GetChunk, IFilter::GetText, next time only constructor and destructor was call on my class.
Also, in next time, after call to constructor I see in output window of visual studio 2012 an exception:First-chance exception at 0x000007fefd44a49d in fdhost.exe: Microsoft C++ exception: CNLBaseException at memory location 0x01022c30.
I haven't found any documentation on this error and on behaviour of fdhost in order to understand where the error is.
Thank you for answer.
Luigi

Problem with accessing database in windows 7 MS Visual Studio

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.