> 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