> On Wed, Jul 3, 2013 at 12:36 PM, HERNAN MARTINEZ FOFFANI
> <hernan.marti...@obi-corp.com> 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
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Reply via email to