How about you testing instead? That's what I do when things aren't working as expected.

You've created a few...

I just tried this, and for me the blocking occurs, exactly as you expected.

Why have you posted this again?

Duplicate post, original here: https://www.sqlservercentral.com/forums/topic/run-time-error-at-system-runtimemethodhandle-invokemethod

Step-by-step debugging is what I would suggest.

I suggest that you compare the schemas of the temp tables with those of the permanent tables and you'll see for yourself.

Alternatively, create the temp tables explicitly (using CREATE TABLE...

easy - would help if you had created a script task (as instructed on the link) instead of a script component.

so do it correctly - script component does NOT...

Sorry … no idea.

At what point do you get that error? Design time, or run time?

I just created a script task and pasted the code in. It built successfully.

That looks like the sort of error you would get if you copied a package containing a project connection from one project to another.

You are right to consider the potential for duplicates. I can't think of an elegant (and fool-proof) way of handling the composite key – so I'd stick with Jonathan's suggestion.

If your actual tables include a PK not mentioned here, you may be able to use that to make your row unique, which would obviate the need for a derived...

It's a Kerberos thing. Get yourself a big cup of tea and read...

You can...

It's a bit hacky, but this avoids the UNION ALL:

WITH Uniqued
AS (SELECT Grouper = IIF(sd.SampleType = 1, 1, CHECKSUM (*))
       ...

Try

SUM(IIF(SampleType = 1, SampleValue,0))