Printable View
I can crash the MS OLE DB Driver for Oracle no problem. All I have to
do is open a CDatasource, open a CSession from that, and try to
execute a stored procedure after disconnecting the cable from the
machine. Crashes every time. Has anyone else ever seen this?
If someone would like source code to reproduce it, I could probably code something up quickly.
Thread split.
No.Quote:
Originally posted by Dr_Cogent
Has anyone else ever seen this?
Do you get an actual Oracle error message when this happens? Something in the server log perhaps?
Unfortunately no. It crashes in the bowels of their DLL and we have no way of recovering at that point.Quote:
Originally posted by slimdave
Do you get an actual Oracle error message when this happens? Something in the server log perhaps?
What's the symptom(s) of the crash?
If the MS OLE DB Driver for Oracle was coded correctly, what should be the outcome for your test?Quote:
Originally posted by Dr_Cogent
I can crash the MS OLE DB Driver for Oracle no problem. All I have to
do is open a CDatasource, open a CSession from that, and try to
execute a stored procedure after disconnecting the cable from the
machine. Crashes every time. Has anyone else ever seen this?
If someone would like source code to reproduce it, I could probably code something up quickly.
Should you get a message saying that the database is no longer available?
It seems that you are upset because you don't like the error hadling for a Microsoft supplied program. Try plugging the cable back and see if it works.
If it does add to the documentation that the network cable must be plugged in. :rolleyes:
All I have to do is open a CDataSource object, open a CSession object based on that CDataSource, pull the cable - and then attempt to execute a stored proc. Crashes every time. It's not something I have control over. It looks like invalid memory is being addressed based on the error (I can look up the exact error if you care to know what it is). It's not like the call just fails and I am returned an error. It dies in the bowels of the MS DLL with no ability to recover. I can even execute the stored proc in a try catch block and catch (...) - doesn't matter.Quote:
Originally posted by slimdave
What's the symptom(s) of the crash?
If you are really interested in seeing this, I can code up a little example to show just how easy it is to crash it.
The problem is, there is no error handling in their code for this condition. The app crashes inside their DLL. I am not returned an error, because it never gets to that point. When I go to the call stack in VS .NET 2003, it doesn't show anything from my program in the stack. It's all in kernel32.dll and the driver if I remember correctly. I could post the call stack in case anyone would like to see it, but I doubt that would help identify what exactly is going on. My guess is, it's a bug in the MS OLE DB for Oracle driver.Quote:
Originally posted by gandolf989
If the MS OLE DB Driver for Oracle was coded correctly, what should be the outcome for your test?
Should you get a message saying that the database is no longer available?
It seems that you are upset because you don't like the error hadling for a Microsoft supplied program. Try plugging the cable back and see if it works.
If it does add to the documentation that the network cable must be plugged in. :rolleyes:
Why don't you either user the native Oracle client or the native Oracle ODBC driver? The first option would be best.
Can you have a timer in your program that times out if it doesn't get a response from the driver? Does someone have an interface coded for .NET to Oracle that will do the error checking for you?
There are many paths that you can go down to get a working and reliable interface. It's a question of doing the research. I'm guessing that no one who read your post really has the answer on how to deal with it.
This is hearsay not evidence: I have been warned NOT to use the MicroSoft Oracle ODBC driver - so I never have. It's claimed to simply not work. So go with Gandolf, use the Oracle version.Quote:
Originally posted by gandolf989
Why don't you either user the native Oracle client or the native Oracle ODBC driver? The first option would be best.
Below is the code that can recreate the problem (it was just a console app that I created). You will need to create a user in Oracle (just make up a quick user with DBA privileges). Contained within the #if block below is the stored proc you will have to add to the user. The problem will only show itself if a successful attempt to execute the stored proc is made. After the successful procedure execution, you will be prompted to yank the network cable. If you do that, it will most certainly crash. If the stored proc doesn't exist, and can't be executed correctly, it will not show the behaviour.
One other thing. I am running a Oracle 9.2.0.1 database and MDAC 2.8 (which includes the MS OLE DB Driver for Oracle)
***************************************
For some reason, I can't post the code here without it getting mangled. You can download the project from here though in a zip file.
http://mywebpages.comcast.net/rwmart...rashSample.zip
So I guess this thread is dead eh?
:confused: :confused:
I think that the thread is dead. You want to code for a condition that should not happen. You can try a different odbc driver, or you can try native drivers, if that is an option. The only other thing that you could try would be to test the connection to make sure that it is still active, everytime you try and access the database. But that seems excessive. Should Microsoft fix this bug? Yes. Will they, maybe.Quote:
Originally posted by Dr_Cogent
So I guess this thread is dead eh?
:confused: :confused:
I have to code for this condition because it very well could happen. Sometimes apps lose their connection to the server and I have to be able to recover from that.Quote:
Originally posted by gandolf989
I think that the thread is dead. You want to code for a condition that should not happen. You can try a different odbc driver, or you can try native drivers, if that is an option. The only other thing that you could try would be to test the connection to make sure that it is still active, everytime you try and access the database. But that seems excessive. Should Microsoft fix this bug? Yes. Will they, maybe.