corelab vs ms Oracle Drivers
-
- Posts: 64
- Joined: Wed 04 Jan 2006 15:32
corelab vs ms Oracle Drivers
Hi
I have been experiencing with an application as I have posted previously (AccessViolationException: Attempted to read or write protected memory)
I have tried everything I can, and the only thing left to do is to remove the OraDirect drivers. Although I am not sure whether this has fixed the problem, I have come across a number of differences between the OraDirect drivers and the built in MS Oracle drivers (with the OracleCommand object).
Firstly with the MS driver the parameters have to be called the same as in the procedure. Doesnt really matter either way but I thought I would mention it.
The MS driver doesnt allow you to set a parameter to Nothing, you have to set it to DBNull.Value. The OraDirect driver does. What happens internally? Does it convert Nothing to DBNull.Value?
The most concerning thing was that the OraDirect drivers seem to allow parameter values that are not of the type you specified them as. For example I realised that some old code was specifying a parameter as a Long and then I was passing in an Int64. This goes back to my old days when I thought that an Oracle Long was a number as opposed to a long string. I know my code was wrong, but I am amazed the drivers allowed it! Also the same happened with Dates/Varchars and int32/numbers.
Shouldn't the OracleCommand object be a little stricter?
Incidentally I notice that version 4 requires 'out' cursors to have their direction specified as output, whereas version 3 doesnt seem to care.
Thanks
Kevin
I have been experiencing with an application as I have posted previously (AccessViolationException: Attempted to read or write protected memory)
I have tried everything I can, and the only thing left to do is to remove the OraDirect drivers. Although I am not sure whether this has fixed the problem, I have come across a number of differences between the OraDirect drivers and the built in MS Oracle drivers (with the OracleCommand object).
Firstly with the MS driver the parameters have to be called the same as in the procedure. Doesnt really matter either way but I thought I would mention it.
The MS driver doesnt allow you to set a parameter to Nothing, you have to set it to DBNull.Value. The OraDirect driver does. What happens internally? Does it convert Nothing to DBNull.Value?
The most concerning thing was that the OraDirect drivers seem to allow parameter values that are not of the type you specified them as. For example I realised that some old code was specifying a parameter as a Long and then I was passing in an Int64. This goes back to my old days when I thought that an Oracle Long was a number as opposed to a long string. I know my code was wrong, but I am amazed the drivers allowed it! Also the same happened with Dates/Varchars and int32/numbers.
Shouldn't the OracleCommand object be a little stricter?
Incidentally I notice that version 4 requires 'out' cursors to have their direction specified as output, whereas version 3 doesnt seem to care.
Thanks
Kevin
-
- Posts: 64
- Joined: Wed 04 Jan 2006 15:32
-
- Posts: 64
- Joined: Wed 04 Jan 2006 15:32
-
- Posts: 64
- Joined: Wed 04 Jan 2006 15:32
-
- Posts: 21
- Joined: Tue 06 Jun 2006 03:14
- Location: Auckland, New Zealand
LOB instead of LONG
Hi,
Wouldn't it be better to use a LOB instead of LONG, as a LONG data type in Oracle has quite a few restrictions on it.
I think Oracle recommends using LOBs as opposed to LONG.
Cheers,
Scott.
Wouldn't it be better to use a LOB instead of LONG, as a LONG data type in Oracle has quite a few restrictions on it.
I think Oracle recommends using LOBs as opposed to LONG.
Cheers,
Scott.
This is a designed behaviour. We are trying to convert any data if the conversion is possible.kevinherring wrote:Thanks Alexey but the most important question remains unanswered.
How come you can pass in an int64 into a parameter you have defined as a Long?
Long is a string.
We can convert any data to a string (except binary data).
-
- Posts: 64
- Joined: Wed 04 Jan 2006 15:32