Hola Sofia Fernandez,
Cuando una migración de base de datos se detiene debido a un campo binario corrupto, la forma más segura de proceder es implementar el manejo de excepciones a nivel de ETL o del script de migración, en lugar de intentar forzar al motor a omitir filas a ciegas. En la mayoría de los frameworks, puedes envolver la operación de inserción o actualización a nivel de fila en un bloque TRY…CATCH (en SQL Server) o en un manejador de errores equivalente en Python o Java, y registrar la clave primaria problemática en una tabla de cuarentena. Esto permite que la migración continúe y, al mismo tiempo, preserva la trazabilidad del registro omitido. Por ejemplo, en SQL Server puedes utilizar una estructura BEGIN TRY INSERT … END TRY BEGIN CATCH INSERT INTO error_log … END CATCH, mientras que en herramientas como Oracle GoldenGate o en pipelines ETL personalizados se configuran archivos de descarte para las filas con formato incorrecto. Una vez finalizada la migración, debes revisar la fila corrupta registrada y decidir si reparas los datos de origen o si la excluyes permanentemente del destino. Este enfoque garantiza que la migración concluya sin quedar bloqueada por un único registro defectuoso, manteniendo a la vez la capacidad de auditar los elementos omitidos.
Si mi respuesta te resulta útil, por favor selecciona "Aceptar respuesta" para apoyarme.
Gracias,
HL.