Thread.Abort() not triggering

Thread.Abort() just raisies the ThreadAborting exception on the thread, which means the Thread has to be transitioning to process the message. If its busy with an IO call, it won't get the message until its done.

ah, well is there any way to just kill it off instantly? because sometimes the query can take up to 10 minutes to process. its a reasonably large database and im running a count query against it.

I think there is a way to do the queries in async mode, and you cancel that way?

async mode? (im sorry i just started with threading)
and how would i cancel that isnt that just another thread?

Instead of killing this thread, you can just signal it to end, and create a new thread (e.g. from a thread pool). You might also want to limit the number of threads per single session.

So, "you should have regular checks" would mean you should raise some "end" flag (or AutoResetEvent or something) without explicitly aborting your previous thread, and make the thread ends itself when it gets the signal.

hmmm, but then the problem is that the start button triggers thread A
when thread A wants to abort and keeps in the query then it wont do much good if it spawns another thread. unless i can make that dynamic.

the query can take up to 10 minutes to process

10 minutes is a long time to wait for a customer, do you think you can somehow avoid a count query?

Also, making a column "NON NULL" might improve performance for COUNT(col_name), because apparently there should be less checks to do in that case (table metadata should already contain the count). Caching the indexes in memory (that should be a server tweak) should also improve performance. Or see if you can get rid of Count if possible.

If thread A is busy waiting for results, and you cannot abort it, then there is no reason to create another thread which will wait for the first thread to finish. Try to identify the exact point at which your thread A blocks, and then you will know what to do.

it usually hangs up at the queries, i have found out that i can cancel the query so i can try to interrupt it like that.
the count is essential since it sets the progressbar maximum value, this will show the user how far the (lengthy) progress is coming along.
i will try column [0] because collumn names could differ

the count is essential since it sets the progressbar maximum value

That is actually what I meant: I would give greater priority to speed than progressbar accuracy (I wouldn't call progressbar essential).

So, if you can get (for example) maximum ID number in your table (which should be much faster than Count), then you can display the progress bar which will update as you move along (even if you don't have some IDs in your table). And progress bar doesn't update while you are getting Count, anyway.

(I understood that Count is the slow query that's giving you the problems, but if other queries are slow also, then it's a different story)

The id numbers arent generated by the database itself, it is all a list of 4 to 8 generated numbers.
i cant make any changes to the database or the server though.

I have to agree with vekipeki here.
If given the choice between accurate statusbar, and having a task take 10minutes less, I would take the 10minutes less.
Most progressbars are just a "guess" anyway.
When I use them, I move them by task, not weight of task.
Like if I have 10 things that need to be done, completeing a task moves the bar 1/10 of the way. Regardless of if one task is very simple and another is very complex.

then it will be no statusbar at all, its just a reader that merges databases... since the amount of records may change a fixed number isnt going to help that much either...

Sounds good. I would recomend a splash screen of sorts that says like "Merging Databases" and if you have it available, everytime a task finishes(or starts) just throw that up on the splash.

"Merging Datasbase: (tablename)"
.
.
.
"Merging Datasbase: (Some ofther tablename)"

i do have something like
"reading row"
"getting parent for <ID>"
and i like having the overview of "completeness" since it can give a little bit of insight on how long it might take.

however i have been told the server used is poo though, so it might as well be that. some other times the query gets through in < 20 seconds...