Existe una actividad en G3 con el mismo nombre y diferente codigo

Buen día, tengo una duda sobre el proceso para migrar las materias (elementos).

En el caso de que la materia exista en g3 el migrador setea las columnas migrar = 0 , existe = 3 (o en 1 - 2 dependiendo del caso) y en la columna elemento coloca el id que corresponde en g3. Hasta ahí vamos bien ya que la materia tiene el mismo nombre y diferente o igual código por lo cual no debería migrarse.
El problema surge cuando queremos migrar esa materia, ya que el migrador setea el id_nuevo con el mismo numero del elemento en g3 (adjunto imagen), en vez de seguir la secuencia de mig._cnv_pk_elementos_seq.
Mi duda es si esto es así por algún motivo, es decir el hecho de que el migrador haga el seteo del id nuevo con el id del elemento en g3 ? o debería seguir la secuencia ?
En caso de querer migrar esa materia yo estoy setando los valores de la columna de la siguiente manera

UPDATE mig._cnv_pk_elementos
SET migrar      = 1,
    codigo_nuevo = concat(codigo, '-FCEQYN'),
    elemento     = id_nuevo
WHERE migrar = 0

Pero al intentar migrar me dice que no se puede insertar una llave duplicada en sga_elementos, ya que como mencionaba mas arriba el migrador esta seteando en id nuevo, el id del elemento en g3.

Nos encontramos en la verison de g3 : 3.19.1

Espero su respuesta

Muchas gracias!


SelecciAn_002.png

SelecciAn_002.png

El problema surge cuando queremos migrar esa materia, ya que el migrador setea el id_nuevo con el mismo numero del elemento en g3 (adjunto imagen), en vez de seguir la secuencia de mig._cnv_pk_elementos_seq.
[b]elemento [/b]= Es la pk de la tabla y corresponde con el nuevo id de elemento a registrar en G3 si la actividad se migra (migrar = 1) Si se define que no se migra (migrar = 0), entonces este campo queda registrado con el id de una actividad que existe en la base de G3; y el dato original de este campo se registra en el campo "[b]id_nuevo[/b]". [b]migrar [/b]= Indica si la actividad se migra o no. Valores: 0 = No se Migra / 1 = Se migra [b]existe [/b]= Define si la actividad existe y de acuerdo a que dato que es igual en la base de G3: Valores: [b]1 [/b]= Existe una actividad en G3 con el mismo código y diferente nombre [b]2[/b] = Existe una actividad en G3 con el mismo codigo y nombre [b]3[/b] = Existe una actividad en G3 con el mismo nombre y diferente codigo

id_nuevo = Registra el dato “elemento” que se insertó originalmente en esta tabla y que en el caso que la actividad no se migre (migrar = 0) se setea con el dato elemento. Esto por si se resuelve que si se desea migrar, entonces se debería camibar migrar a 1 y elemento con el dato de esta columna.

Por eso, si luego de decidir que una actividad se migra, entonces se vuelve a setear el valor del campo “elemento” con lo que se habia registrado en el campo “id_nuevo”:

UPDATE mig._cnv_pk_elementos
SET migrar      = 1,
    codigo_nuevo = concat(codigo, '-FCEQYN'),
    elemento     = id_nuevo
WHERE migrar = 0
En caso de querer migrar esa materia yo estoy setando los valores de la columna de la siguiente manera

Código: [Seleccionar]
UPDATE mig._cnv_pk_elementos
SET migrar = 1,
codigo_nuevo = concat(codigo, ‘-FCEQYN’),
elemento = id_nuevo
WHERE migrar = 0


Es correcto lo que estas haciendo.

Hay un error en el código donde hace el UPDATE sobre la tabla mig._cnv_pk_elementos
Adjunto el script de migracion. Reemplazalo y vuelvan a probar.
Carpeta: \02_Modulos\05_Tablas_Comunes
Luego de correr volver a migrar con este nuevo script, consulten la tabla mig._cnv_pk_elementos y vean que actividades van a querer migrar y volviendo a setear el campo “elemento” con el dato “id_nuevo”.

SELECT * FROM mig._cnv_pk_elementos WHERE migrar = 0;

01_tablas_conversion.sql (35.8 KB)

Hola alejandro gracias por tu pronta respuesta, efectivamente entiendo que ese es el funcionamiento del migrador pero en este caso (fijate en la imagen adjunta del primer comentario) me esta seteando el id_nuevo con el id que tiene en g3 el elemento y no con el id nuevo que yo deberia poder usar para poder migrar.

Fijate que modifique el mensaje anterior y adjunte el script de migracion con unos cambios.

Ahi pise el script de 01_tablas_conversion.sql pero al correr el script obtengo el siguiente resultado en spoon

2022/05/16 10:51:01 - 01_tablas_conversion - ERROR: llave duplicada viola restricción de unicidad «pk_cnv_pk_elementos»
2022/05/16 10:51:01 - 01_tablas_conversion - Detail: Ya existe la llave (elemento)=(568).
2022/05/16 10:51:01 - 01_tablas_conversion - Where: sentencia SQL: «UPDATE mig._cnv_pk_elementos
2022/05/16 10:51:01 - 01_tablas_conversion - SET elemento = _elemento_g3,
2022/05/16 10:51:01 - 01_tablas_conversion - existe = 3,
2022/05/16 10:51:01 - 01_tablas_conversion - id_nuevo = elemento,
2022/05/16 10:51:01 - 01_tablas_conversion - observaciones = 'Existe una actividad en G3 con el mismo nombre y diferente codigo: ’ || _codigo_nombre_g3
2022/05/16 10:51:01 - 01_tablas_conversion - WHERE elemento = cur_g2.elemento»
2022/05/16 10:51:01 - 01_tablas_conversion - función PL/pgSQL mig.aux_pk_materias() en la línea 90 en sentencia SQL

Si, quedo mal, lo deje como estaba originalmente pero con unas mejoras. Adjunto nuevamente el script.
Las opciones existe con valor 1 y 3 se migran, pero se advierte que hay al menos una actividad en G3 con mismo código o nombre
La opción existe con valor 2, no se migra porque existe una actividad enG3 con mismo codigo y nombre.

Deberias consultar la tabla con:

SELECT * FROM mig._cnv_pk_elementos WHERE existe > 0 ORDER BY migrar, codigo;

01_tablas_conversion.sql (35.9 KB)

Ahora si ! paso todos los modulos de migacion

Muchas gracias Alejandro por tu respuesta

Saludos cordiales