Aborting a thread corrupts my SqlConnection (?)

[Uri Dor]

Hi,
I'm running a long query in a separate thread. If I abort that thread
and then I try to use the same connection string again, I get an
unexpected result.
Details:

the aborted thread runs a query that returns a resultset, using a
DataAdapter.
the query run afterwards is:
INSERT INTO Report_selection_ids DEFAULT VALUES; SELECT SCOPE_IDENTITY()

which usually returns an integer, but if executed after the resultset
query thread was killed, it returns what seems to be the 1st field of
the 1st record of the recordset, which happens to be a string.

I've seen posts on a similar problem in framework 1.0, which was
supposed to be fixed long ago.

I'm using framework 1.1 (no SP - is there one?)

thx
Uri

 

[Miha Markic [MVP C#]]

Hi,
I'm running a long query in a separate thread. If I abort that thread and
then I try to use the same connection string again, I get an unexpected
result.
Details:

the aborted thread runs a query that returns a resultset, using a
DataAdapter.
the query run afterwards is:
INSERT INTO Report_selection_ids DEFAULT VALUES; SELECT SCOPE_IDENTITY()

which usually returns an integer, but if executed after the resultset
query thread was killed, it returns what seems to be the 1st field of the
1st record of the recordset, which happens to be a string.

I've seen posts on a similar problem in framework 1.0, which was supposed
to be fixed long ago.

I'm using framework 1.1 (no SP - is there one?)

Yes, there is sp1.
However, you really shouldn't kill threads - rather use sync mechanisms to
signal to thread to finish.
Btw, how exactly are you killing the thread?
Are you creating a new instance of conneciton object for the new query?

 

[Uri Dor]

Thanks for your reply, Miha.
I installed sp1, but the problem is still reproducible.
I'm killing the thread using Thread.Abort() and treating the exception.
I'm not aware of any sync mechanism that can stop a
SqlDataAdapter.Fill() call - are you?
Regarding the connections - the killed thread uses its own SqlConnection
instance, although it uses the same connection string so it's pooled.

What's the standard way to do such a thing - basically, to call
DataAdapter.Fill and then interrupt it?

 

[Miha Markic [MVP C#]]

Thanks for your reply, Miha.
I installed sp1, but the problem is still reproducible.
I'm killing the thread using Thread.Abort() and treating the exception.
I'm not aware of any sync mechanism that can stop a SqlDataAdapter.Fill()
call - are you?

No, there aren't.
However, you might throw an exception within RowChanged event (I am not sure
if this would stop the Fill process though).

Regarding the connections - the killed thread uses its own SqlConnection
instance, although it uses the same connection string so it's pooled.
Interesting.

What's the standard way to do such a thing - basically, to call
DataAdapter.Fill and then interrupt it?

Try the suggestion above and see what happens and let us know.

 

[Pablo Castro [MS]]

Killing a thread is always dangerous. If at all possible you should avoid
doing that. One option for the Fill case is to try to use the Cancel()
method in the command object (adapter.SelectCommand.Cancel()). Depending on
where the command processing is, it may help.

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.