Using ODP.NET connection for executing ADODB Command object

[Sandeep Limaye]

Hi,

I'm connecting to Oracle 9i database using ODP.NET (Using the
OracleConnection class). Can I use the same currently open connection for
executing a stored procedure / query through an ADODB.Command object?

I want to do something like this:

void ExecuteCommandObject ( ADODB.Command oAdoDbComm )
{
// ( I have this connection already open, just pasted the code here )
OracleConnection oOraConn = new OracleConnection (
strMyConnectionString );
oOraConn.Open ( );

// Statement giving me error
oAdoDbComm.ActiveConnection = ( ADODB.Connection ) oOraConn;

oAdoComm.Execute ( ... );
}


I may be expecting a bit too much, but is there any way that I can achieve
this? I do not want to open a separate connection through ADODB.Connection,
and I also do not want to convert the ADODB.Command object to an
OracleCommand because the two differ greatly in their "CommandText" formats,
and it's a great pain if the CommandText is complex and has parameter
holders.

Thanks in advance,
Sandeep

 

[David Browne]

Hi,

I'm connecting to Oracle 9i database using ODP.NET (Using the
OracleConnection class). Can I use the same currently open connection for
executing a stored procedure / query through an ADODB.Command object?

No. That cannot be done.

I may be expecting a bit too much, but is there any way that I can achieve
this? I do not want to open a separate connection through ADODB.Connection,
and I also do not want to convert the ADODB.Command object to an
OracleCommand because the two differ greatly in their "CommandText" formats,
and it's a great pain if the CommandText is complex and has parameter
holders.

You really should byte the bullet and get rid of old ADO.
ODP.NET binds parameters by position, or by name, whichever you prefer, and
it uses exactly the same "CommandText" format as PL/SQL and SQLPlus. So as
an added bonus, you can cut and paste from Visual Studio into Toad or
SQLPlus or whatever.

David

 

[Sandeep Limaye]

Thanks David...yes, I agree that at some point in time we must get rid of
the old ADO and move on. But we need to provide some means of catering for
existing COM clients (that are not willing to move on, or will take some
time to move on) that pass the old ADO command objects to the
database-accessing component that has adhered to the newer data providers
(like ODP.NET).

Thanks again,
Sandeep