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))

Like this?

WITH qry1
AS (SELECT *
    FROM
    (
        VALUES
      ...

How many tables are updated during this process?

Does each table have date created / date modified columns?

Is the incoming data purely inserts, or inserts + updates, or inserts + updates...