Without execution plans, I'm guessing here.

Changes in statistics caused a change in execution plans. Changes in data caused a change in behavior (as data changes, row counts change, which causes...

AH!!!

Sorry. I really did misunderstand.

So, Ken is right. Don't do that. That is two, distinct queries. While yes, there are ways to force them into a single procedure or batch,...

It's just a loop that's needed. Try using the SELECT statement above and create a cursor. Then execute an a dynamic statement with the kill and the session_id value.

Ah, and another clarification. I was wrong about the numbers being statements. It's count of lines of code that the tool thinks may have problems. That's why one tab has...

I did a little more research and testing and I've got it. "M" in this case means that you've got a script that's in source control. You've made changes to...

I think I've got it. The M, not sure why M, appeared when I had an uncommitted change in source control. I staged it and then committed it, and the...

The number I have. It's the number of statements that have perceived problems.

Those three tabs have exactly that number of SQL statements in each that looked wrong...

• This reply was modified 5 years ago by Grant Fritchey.

I'm leaning toward what Scott says. Check the model database.

You'll want to reference sys.dm_exec_requests. That's the DMV that shows actively running queries. Combine it with sys.dm_exec_sql_text to search for a string that's currently running something like this:

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"

- Theodore Roosevelt
Author of:

SQL Server Execution Plans

SQL Server Query Performance Tuning