I admit, I don't expect IIF to go away (ever), as bad an idea as it was to corrupt T-SQL with it.  I'm just hoping they don't bring over things...

I was worried about potential performance issuing in the subquery methods, at least for larger numbers of rows.

For smaller numbers of rows, the subquery may in fact perform somewhat better.

by the way, since we already have touched the subject,

is it a good idea at all to execute anything like this on a remote server as EXEC  (...)  AT...

I don't know of one.  And I don't see the value of it.  First, if the statement appears in a loop, you'd have to multiply the cost.  Second, not all...

exec ('CREATE OR ALTER PROCEDURE ins_tmp_proc AS

BEGIN

INSERT INTO dbo.tmp (job_id, name, ..., server)

SELECT job_id, name, ..., @@SERVERNAME from msdb.dbo.sysjobs

UNION ALL

SELECT job_id, name, ..., ''<remoteserver>'' from <remoteServer>.msdb.dbo.sysjobs

END')

UPDATE CT --<<-- this MUST be CT, NOT CallTable
SET Fname = ISNULL(Fname_Max, Fname), Lname = ISNULL(Lname_Max, Lname)
FROM CallTable CT
INNER JOIN (
    SELECT CallID, MAX(Fname)...

CONCAT and CONVERT do not work on conditions, i.e. comparisons.  They work on expressions, as do all SQL functions.

That's why I used IF to compare to IIF -- it's one...

CASE, ISNULL and COALESCE are all an integral part of SQL Server and follow its general syntax.  It's because IIF is so unlike other other functions and expressions...

A clustered index would be the best chance to avoid deadlocks.  So there are roughly 60K rows for each column1 value?  And you want to change all of them in...

If there's no index at all, might as well make it a clus index on column1.  Yes, an index should help, since it will avoid scanning the whole table for...

CASE, ISNULL and COALESCE are all an integral part of SQL Server and follow its general syntax.  It's because IIF is so unlike other other functions and expressions in SQL...

Does the table have an index with column1 in it, or preferably where column1 is the first column in an index?  If no, SQL would have to scan the table...

If the main table is really that narrow (few bytes), then compress the non-clus index to reduce the pages more:

CREATE UNIQUE NONCLUSTERED INDEX IX1_IattribINT ON dbo.AttribINT (...

I'd suggest first try creating a non-clustered index on ( OID, AID ).  Cluster the temp table on ( OID /*and AID if available*/ ).

CREATE UNIQUE NONCLUSTERED...

Need to see the DDL for AttribINT, including all index definitions.