I understand the pitfalls of NOLOCK and the possibilities of dirty reads.

I am confused why 'SELECT DISTINCT' will not resolve the duplicate rows into one distinct row.

Your answer makes me feel a little better.

I am not sure that I can run your query exactly as requested.

This particular query could return up to 90,000 rows.

I would have...

The table that I am querying is too hot of a table to turn snapshot processing on.

I am more curious as to why DISTINCT does not work here.

@AbsTab is a declared table variable

Sorry...my bad:blush:

remove abstabid from the PK

that was a remnant from my previous testing...jugling a lot of stuff

Not sure exactly what your asking.

This is a table variable so all inserts are isolated to this process.

The plan is not taking advantage of parallelism.

Let me know if this does...

That was exactly where I was headed next.

Thank you for this information.

I will abandon my fruitless plans of performing the sp_recompile's.

It may take some time to gather up some examples...

ok, then you are stating that an sp_recompile is NOT needed after the batch 'Update Statistics'.

That makes sense since there is no major data manipulation going on that would...