> On Wed, Jul 3, 2013 at 12:36 PM, HERNAN MARTINEZ FOFFANI
> <[email protected]> wrote:
>> I have a wrapper class that abstracts some layers and on some database
>> engines (I don't remember which one, it might be SQLServer) if you call
>> Close() on a command whose reader weren't consumed the Close() keeps
>> reading the records up to the end. So as a sanity measure I added a Cancel()
>
> That might be a lot of wasting, in case of huge resultset and blobs.
Care to elaborate? You mean the check I mentioned in the next paragraph
or something else?
Some pseudo code
canceling = false;
reader = command.ExecuteQuery();
foreach ( row in reader ) {
canceling = process ( row );
// someone sets canceling, doesn't need the rest of the resultset.
if (canceling)
break;
}
if (canceling) // <- this check is what I added today.
command.Cancel(); // <- this call was unconditionally before.
reader.Close();
command.Close();
Close() …etc… goes in a finally clause. In real code I'm catching exceptions
to quit cleanly.
The Cancel() is needed because closing a data reader with pending data
keeps reading until the end of the data set. I don't remember which provider
did that (SqlServer or Oracle?)
>
>> in the Dispose() method of the wrapper.
>>
>> I've just modified the wrapper and instead of calling Cancel()
>> unconditionally
>> it first check if the DataReader was consumed or not and only cancel if it
>> wasn't.
>
> That's first step. ;)
Ugh.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Firebird-net-provider mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
