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.