Even back to the DBLib days, I didn't recommend use of the "cancel" call as
it sometimes took quite a toll on the server. Consider that the server is
running asynchronously--like a cook in a big restaurant. Your query might be
well along in the preparation phase, the completed rowset might be in the
process of being returned or the process might be blocked by some other
operation. Submitting a "cancel" won't make SS mad (as it might make the
cook mad after having gone to the trouble of making your lobster thermador),
but it might take some time to "put back" (rollback) the operation. Consider
that if the cancel is not complete, the connection is not really capable of
dealing with another operation so this might be the side-effect.
hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"dubian" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I apologize, I was feeling rushed when I initially posted and obviously
> did a poor job with the details.
>
> I created a C# com control to use ADO.NET 1.1 with the SqlClient as the
> DB connectivity tool.
>
> When I call 'command.Cancel()', on occasion I get the above
> exception and the connection closes. I get an 'attention' when I
> monitor with the SQL profile but cannot find the cause or details of
> the attention entry.
>
> If I remove the call to cancel, (which is being called before every new
> querry), the exception is never seen.
>
> Code sample.
>
> EstablishNewConnection and command associated with connection.
>
> For each new command against server:
>
> Command.Cancel()
> anyOpenReaderOnConnection.Close()
> Command.CommandText = "sql command"
> Command.CommandTimeout() = value
> Command.ExecuteReader()
>
> Work with Reader.....
>
>
> It is when ExecuteReader is called, that the exception is thrown on
> occasion. I feel there is some 'racecondition' somewhere getting
> mangled by repeatedly calling cancel and that sometimes the cancel is
> actually forwarded to the server after ExecuteReader is called. Or
> something like that.
>
> Thanks.
>