Tengo una clave principal de dos columnas en una tabla. He intentado cambiar a establecer el ignore_dup_key a continuar con este comando:¿Puedo establecer ignore_dup_key para una clave principal?
ALTER INDEX PK_mypk on MyTable
SET (IGNORE_DUP_KEY = ON);
pero me sale este error:
Cannot use index option ignore_dup_key to alter index 'PK_mypk' as it enforces a primary or unique constraint.
¿Cómo, si he de poner a IGNORE_DUP_KEY en?
No está documentado en los Libros en pantalla, pero he encontrado que si bien esto es válido para las claves principales, no puede cambiar esto con un ALTER INDEX, tendrá que soltar y volver a crear la clave principal.
Tenga en cuenta que esta bandera no permite que le permite almacenar las filas duplicadas en realidad, simplemente se cambia el error que se produce:
ON
A warning message will occur when duplicate key values are inserted into a unique
index. Only the rows violating the uniqueness constraint will fail.
OFF
An error message will occur when duplicate key values are inserted into a
unique index. The entire INSERT operation will be rolled back.
Determina lo que ocurre cuando se inserta duplicados sólo se
Specifies the error response when an insert operation attempts to insert duplicate key values into a unique index. The IGNORE_DUP_KEY option applies only to insert operations after the index is created or rebuilt. The option has no effect when executing CREATE INDEX, ALTER INDEX, or UPDATE.
..y no se aplica a PK
El comentario BOL para ALTER TABLE sobre esto y la "compatibilidad hacia atrás" es algo confusa. Lo probé y BradC está en lo cierto.
CREATE TABLE dbo.foo (bar int PRIMARY KEY WITH (FILLFACTOR=90, IGNORE_DUP_KEY = ON))
GO
INSERT dbo.foo VALUES (1)
GO
INSERT dbo.foo VALUES (1)
GO
--gives
(1 row(s) affected)
Duplicate key was ignored.
(0 row(s) affected)
Tenga en cuenta que este ajuste sólo afecta a lo que ocurre si se intenta insertar una clave duplicada, no se permitirá insertar una clave duplicada.
Si está intentando insertar claves duplicadas, puede soltar el índice de la clave principal, insertar sus registros, corregir los datos (eliminar duplicados, etc.) y luego volver a crear el índice.
Personalmente nunca quieren hacer caso omiso de la duplicar. Si hay un valor duplicado en una clave principal, debe corregirse. No quiero que se ignore y los otros registros se insertan porque entonces el usuario podría pensar que todos se insertaron. Esta configuración es un encubrimiento para un mal proceso de inserción. Un proceso bien diseñado no necesita este ajuste, ya que limpia los datos antes de ingresarlos (o usa la inserción para actualizar los existentes e inserta los nuevos) y envía los registros incorrectos a una tabla para que puedan ser reparados y reinsertados o envíe un error de vuelta al usuario, para que sepan que su registro no fue insertado.
ALTER TABLE [TableName] REBUILD WITH (IGNORE_DUP_KEY = ON)
Mi problema es este: Tengo que insertar una gran cantidad de registros diariamente y actualmente estoy haciendo un comando de inserción para cada registro. Si el registro ya existe, se ignorará (lanzando un error de clave duplicado). Desde un POV de rendimiento, es mejor intentar una inserción y permitir que algunos fallen, de lo que es verificar si el registro existe antes de insertar. El siguiente paso para mejorar el rendimiento es usar SqlBulkCopy para hacer las inserciones en lugar de un único comando para cada registro. Pero esto no es posible si existe algún registro, ya que todo el lote falla si ignore_dup_key está desactivado. –
¿Qué ocurre si una de las columnas de mi clave principal está definida por el usuario? ¿Y qué sucede si necesito admitir inserciones de varias entidades al mismo tiempo, digamos 1000? ¿Cómo puedo validar que todas las entradas son únicas antes de la inserción sin un fuerte golpe para el servidor?Creo que la opción de ignorar duplicados es bastante apropiada en esa situación. ¿Estás en desacuerdo? – julealgon
Sí, no tiene la clave principal si ignora los duplicados y, si lo hace, si tiene una clave principal, tendrá un mundo lastimado con datos erróneos. Es una mejor práctica colocar los datos en una tabla de etapas y luego usar una instrucción de selección para insertar solo los nuevos registros. Insertamos millones de registros de esta manera. – HLGEM