tags:

views:

128

answers:

2

Hi, On the classs level, I have declared:

System::Data::Odbc::OdbcConnection conn;
System::Data::Odbc::OdbcDataReader datareader; //doesnt work
System::Data::Odbc::OdbcDataReader^  datareader //works

However, the dataReader has to be OdbcDataReader^. I dont understand why. Thanks

A: 

I'm not sure if this answers your question but here goes:

Connection and DataReader classes come in pairs on the .NET Framework, depending on the database technology used. So you have OdbcConnection and OdbcDataReader, also SqlConnection and SqlDataReader, etc. You have always to use them in pairs. Note anyway that all of these implement the common interfaces IDataConnection and IDataReader.

EDIT. Fine, I completely misunderstood the question. :-/

I usually use C#, not C++, but I think that it is because you can directly create a new instance of OdbcConnection, but as for the OdbcDataReader, you need to obtain an instance by executing the ExecuteReader method on the corresponding OdbcCommand. ExecuteReader returns a pointer to a new OdbcDataReader object.

Konamiman
Thanks, but my question is why I dont need use handle with odbcconnection, while I have to useOdbcDataReader^?
Petr
A: 

With OdbcConnection conn; you are instantiating a connection object directly (on the stack). Not sure if that is a good idea but it is possible.

You cannot do that with a OdbcDataReader datareader; because that class only has hidden (private/internal) constructors. That is by design, you are not supposed to create DataReaders directly but instead get them from a call to ExecuteReader(). And ExecuteReader returns OdbcDataReader^ . See MSDN.

Henk Holterman
I need to instantionate connection directly because many methods share it and its also passed to other classes as parameter.
Petr
Petr, if you need to share the connection then you probably _do_ want a reference (managed pointer).
Henk Holterman
whilst the second para of this answer is helpful, the first is factually incorrect - Despite syntactic appearances, the instance is not created on the stack, it's still on the managed heap; it's just that it is deterministically disposed when the scope ends.
tragomaskhalos
Ok, thanks. I know C# and C++ but not the CLI stuff. Feel free to edit, or copy paste to your own answer.
Henk Holterman