La mejor opción en mi caso para actualizar múltiples registros es utilizar la combinación de consultas (Compatible con SQL Server 2008), en esta consulta tiene control total de lo que está actualizando. También puede usar la consulta de salida para realizar un procesamiento posterior.
Ejemplo: Sin cláusula de salida (sólo actualización)
;WITH cteB AS
(SELECT Id, Col1, Col2, Col3
FROM B WHERE Id > 10 ---- Select Multiple records
)
MERGE A
USING cteB
ON(A.Id = cteB.Id) -- Update condition
WHEN MATCHED THEN UPDATE
SET
A.Col1 = cteB.Col1, --Note: Update condition i.e; A.Id = cteB.Id cant appear here again.
A.Col2 = cteB.Col2,
A.Col3 = cteB.Col3;
Ejemplo: Con la cláusula OputPut
CREATE TABLE #TempOutPutTable
{
PkId INT NOT NULL,
Col1 VARCHAR(50),
Col2 VARCHAR(50)
}
;WITH cteB AS
(SELECT Id, Col1, Col2, Col3
FROM B WHERE Id > 10
)
MERGE A
USING cteB
ON(A.Id = cteB.Id)
WHEN MATCHED THEN UPDATE
SET
A.Col1 = cteB.Col1,
A.Col2 = cteB.Col2,
A.Col3 = cteB.Col3
OUTPUT
INSERTED.Id, cteB.Col1, A.Col2 INTO #TempOutPutTable;
--Do what ever you want with the data in temporary table
SELECT * FROM #TempOutPutTable; -- you can check here which records are updated.
@bluefeet - ¿Siempre? Pensé que este comportamiento dependería de la optimización del índice. Es decir, el orden en SQL no está garantizado en sentencias 'SELECT' a menos que se especifique una cláusula' ORDER BY'. Y desafortunadamente, este comportamiento no es trivialmente comprobable. El hecho de que no arroje un error (para algo como 'declaración devolvió más de un resultado') también me molesta. Estoy un poco receloso de 'JOIN's en' UPDATE's, por esta razón (a pesar de que puede haber simplificado algunas de las cosas que tenía que hacer en DB2). –
No tiene datos para probar esto? Parece que deberías poder decirle a todos los demás. – JeffO
@ X-Zero, puedo confirmar que una actualización con una fila unida en varias filas no es determinista. ¿Cómo es esto posible? Cuando pienso en las computadoras, creo que es determinista, esto es algo inusual para mí. – sooprise