Calling Class

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I call a class in my windows service app and in that class I access a
method that returns an OleDbReader. Now It does have records in the reader
when I step through the method but when I return to calling class the
OleDbReader dr is null.
What am I missing here?

Class1 calls Class2.Method which returns a OleDbReader. Class1's OleDbReader
is null.

OleDbReader dr = Class2.GetRecords();

JJ
 
We can't tell you the problem if you don't post the content of the
GetRecords method. Or a reproduceable test case that shows the problem.
 
Calling Class1 method below:

private void GetUPS(string Path, bool CNote)
{
OleDbDataReader dr = blda.GetAccRecs(Path);

try
{
while(dr.Read())
{
}
catch(Exception ex)
{
string sEMess = "";

sEMess = ex.Message;
}


}
Other Class2 Method being called:

public OleDbDataReader GetAccRecs(string aPath)
{
OleDbConnection AccCon = new
OleDbConnection(Dev_Acc_Con1);
try
{
sSQL = "SELECT * FROM Customers";
OleDbCommand cmdUPS = new OleDbCommand();
cmdUPS.Connection = AccCon;
cmdUPS.CommandType = CommandType.Text;
cmdUPS.CommandText = sSQL;
AccCon.Open();

dr2 = cmdUPS.ExecuteReader();

return dr2;
}

So this procedure gets called and returns an OleDbReader to calling Class1.
I have checked there are records that get returned to Class1 but when Code
Statement
while(dr.Read()) gets executed, it bombs out and gives me this error:
"Invalid attempt to Read when reader is closed."

Any ideas as to why?

Thanks,

JJ
 
I'm not 100% positive, but I suspect your problem may be that the associated
OleDbConnection is closed. Since you are declaring the connection inside
your get method, it is only valid in this context. After GetAccRecs returns
the connection object is disposed of (and thus closed). The error message
about the closed OleDbDataReader seems consistent with this assumption.

Ideally, you should process your data inside GetAccRecs and properly close
both the reader and the connection after you're done. If you really must
process your data outside GetAccRecs, try writing it to another data
structure (maybe a DataSet) and returning a reference to this object. Theat
way you can safely close your connection before returning from GetAccRecs.
--
Kai Brinkmann [Microsoft]

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
 
So that is not the same then as the method returning null. Those are 2 very
very very different things.

You are not showing what is after the 'try' block, but I suspect you have a
finally block afterwards, that is closing the connection.

A datareader requires an open and active connection to the database, since
it retrieves one row at a time. It is usually not a good idea to return
datareaders to callers outside the class, since they have to be responsible
for closing the connection - and if the developer forgets, you get
connection leaks.

You should fill a datatable instead, and return that.
 
Kai Brinkmann said:
Since you are declaring the connection inside
your get method, it is only valid in this context. After GetAccRecs returns
the connection object is disposed of (and thus closed).
Click to expand...

Huh? I pass SqlDataReader objects out of function results all the time with
no problem. Why would the data reader be disposed? It is always referenced!
 
JJ said:
public OleDbDataReader GetAccRecs(string aPath)
{
OleDbConnection AccCon = new
OleDbConnection(Dev_Acc_Con1);
try
{
sSQL = "SELECT * FROM Customers";
OleDbCommand cmdUPS = new OleDbCommand();
cmdUPS.Connection = AccCon;
cmdUPS.CommandType = CommandType.Text;
cmdUPS.CommandText = sSQL;
AccCon.Open();

dr2 = cmdUPS.ExecuteReader();

return dr2;
}
Click to expand...

So this function never ends? ;-)

As Marina astutely pointed out, I bet you've got the following code that you
didn't post:

finally
{
// Some code that closes the data reader and/or connection.
}
}


The "finally" part of a "try..finally" will *ALWAYS* execute. That's why the
data reader is closed when the calling procedure tries to read from it.

Should I append my "single exit point" script here? ;-)
 
I didn't say the reader was disposed! (It's not because there's still a
valid reference to it.) What I did say is that I suspected the *connection*
that the reader relies on was closed.
--
Kai Brinkmann [Microsoft]

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top