Migracion de G2 a un G3 (v3.15.1) con Datos Responsables Academica

Hola:

Estamos migrado desde G2 a G3 (Con Datos Ya cargados), y queremos unificar los responsables academicos, ya que son los mismos:

– Ya estan en G3
– responsable_academica nombre codigo responsable_academica_tipo
– 8 “Escuela Universitaria de Artes” “EAU” 102
– 3 “Departamento de Ciencias Sociales” “CS” 2
– 4 “Departamento de Ciencia y Tecnología” “CYT” 2
– 5 “Departamento de Economía y Administración” “DEYA” 2

– En G2 (Despues de migrar)
– responsable_academica nombre codigo responsable_academica_tipo
– 11 “Universidad Nacional de Quilmes” “UA UNQ” 1
– 12 “Departamento de Ciencias Sociales” “D A” 2
– 13 “Departamento de Ciencia y Tecnología” “D B” 2
– 14 “Escuela Universitaria de Artes” “D D” 2
– 15 “Departamento de Economía y Administración” “D C” 2

Realice los paso que se definieron en “http://foro.comunidad.siu.edu.ar/index.php?topic=11391.msg49292” :

Resumo en el foro lo que resolvimos por GDS:
Se realizará para la próxima versión un ajuste en la tabla _cnv_pk_departamentos para adaptarla al esquema de las tablas comunes (columnas existe, migrar, codigo nuevo).

Mientras tanto, con el esquema que existe actualmente, se brinda la siguiente solución:

  1. Migrar toda la base de G2.
    Esto creará un nuevo registro de responsable académica para esa unidad académica que estas migrando. Tabla sga_responsables_academicas.

  2. Una vez finalizada toda la migracion de la base de la sede, recuperar el dato de la responsable académica que queres utilizar (la de la primer base que migraste) y cambiar en las tablas los ids del campo “responsable_academica” de la base que terminas de migrar (el que corresponde a la unidad académica, el cual se inserta con el tipo de responsable academica 1 = Facultad).
    Supongamos que la migración generó un nuevo registro con el id de responsable académica nro 5. Para cambiar la responsable académica 5 por la 1 (el id que corresponde a la 1er base migrada y la que queres utilizar para todas las sedes). Las tablas son las siguientes:
    UPDATE gde_responsables_academicas SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE men_dominio SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE sga_certificados_ra SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE sga_convenios_ra SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE sga_docentes_ra SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE sga_documentos_ra SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE sga_elementos_ra SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE sga_propuestas_ext SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE sga_propuestas_ra SET responsable_academica = 1 WHERE responsable_academica = 5;
    UPDATE sga_ug_responsables_academicas SET responsable_academica = 1 WHERE responsable_academica = 5;

y no se resolvio.
Osea tendrian que quedar como responsables academicos los que estaban en G3. Y despues seria necesario eliminar los responsables 11,12,13,14,15.
Falto algun paso?.

Muchas gracias!!!

¿Intentaste eliminar la responsable academica nro 5 y aun hay alguna tabla que hace referencia a esa responsable academica?
¿Que fue lo que no funciono?

Hola:

Comenzamos a migrar desde 3.17.0, lo que hice para que no me aparezcan duplicados(Estamos en etapa de testeo) fue, reemplazar los dptos, en G2(Base G2 de desarrollo) con los codigos de G3, actualizando las tablas tambien relacionadas:

– Se insertan los codigos de departamentos en G3, luego se actualizan sga_carreras,sga_materias, con los nuevos codigos y posteriormente se eliminan
– los codigos que tenia antiguamente G2
– select * from sga_departamentos

– depatamento nombre
– A Departamento de Ciencias Sociales
– B Departamento de Ciencia y Tecnología
– C Departamento de Economía y Administración
– D Escuela Universitaria de Artes

– INSERT INTO sga_departamentos VALUES(‘UNQ’,‘CS’,‘Departamento de Ciencias Sociales’,‘A’);
– INSERT INTO sga_departamentos VALUES(‘UNQ’,‘CYT’,‘Departamento de Ciencia y Tecnología’,‘A’);
– INSERT INTO sga_departamentos VALUES(‘UNQ’,‘DEYA’,‘Departamento de Economía y Administración’,‘A’);
– INSERT INTO sga_departamentos VALUES(‘UNQ’,‘EAU’,‘Escuela Universitaria de Artes’,‘A’);

– Tablas que hace referencia el DEPARTAMENTO.
– select * from sga_docentes_dpto – NADA (No tenemos datos)
– select * from sga_carreras;
– select * from sga_materias;

SET triggers for sga_departamentos disabled;
SET triggers for sga_carreras disabled;
SET triggers for sga_materias disabled;

update sga_carreras set departamento = ‘CS’ WHERE departamento = ‘A’;
update sga_carreras set departamento = ‘CYT’ WHERE departamento = ‘B’;
update sga_carreras set departamento = ‘EAU’ WHERE departamento = ‘D’;
update sga_carreras set departamento = ‘DEYA’ WHERE departamento = ‘C’;

update sga_materias set departamento = ‘CS’ WHERE departamento = ‘A’;
update sga_materias set departamento = ‘CYT’ WHERE departamento = ‘B’;
update sga_materias set departamento = ‘EAU’ WHERE departamento = ‘D’;
update sga_materias set departamento = ‘DEYA’ WHERE departamento = ‘C’;

SET triggers for sga_departamentos enabled;
SET triggers for sga_carreras enabled;
SET triggers for sga_materias enabled;

– delete from sga_departamentos where departamento In(‘A’,‘B’,‘C’,‘D’)

, y ya no me parecieron duplicados.
Los updates no actualizaba nada.

Muchas gracias!!!

En la migración, los departamentos (de G2) que se migran a G3 como responsables academicas, no se migran si existe un departamento en G2 con el valor en el campo sga_departamentos.departamento una responsable académica de tipo departamento con el mismo codigo (sga_responsables_academicas.codigo).
Y para no hacer todo ese cambio en G2 o en las tablas del esquema mig, lo que podes hacer es luego de migrar el módulo “05_Tablas_Comunes”, es consultar la tabla de migracion mig._cnv_pk_departamentos y reemplazar el dato del campo “responsable_academica” por el valor de la responsable academica de Guarani 3 que represente al mismo departamento a migrar, y seteando el valor “migrar = 0”. De esta forma no lo migrará y todos los datos relacionados con este departamento en la base de G2 quedará asociado a la responsable academica de G3 de ese departamento.

Buenas tardes

Estamos intentando unificar Responsables Académicas sin éxito. Buscando en el foro encontramos este hilo que se corresponde con lo que hicimos pero no nos dio resultado.

Por lo que vimos el script de migración compara el código de la RA en negocio con la RA de la carrera que migra. Por qué utiliza el código y no el id?

Saludos

Las Responsables Academicas en G3 se generan a partir de la migracion de la Unidad Academica y Departamentos de G2. En estos casos el código de la unidad academica y de los departamentos pasan a definirse como código en la responsable académica.
El dato que es la pk de la tabla sga_esponsables_academicas es un campo autoincremental (responsable_academica) que no existe en la base de G2.

Estamos intentando unificar Responsables Académicas sin éxito.
¿Como lo estan haciendo? ¿Durante el proceso de migración o despues de haber migrado unificando RAs en la base de G3?

2

Estamos intentando hacerlo durante la migración indicando que la RA existe

Para ello vean de ajustar el archivo 02_Modulos\05_Tablas_Comunes\01_tablas_conversion.sql , donde hace el seteo del id de la responsable academica de G3 para la unidad académica si es que ya existe.
Tabla mig.cnv_pk_departamentos

Buen día!

Nos encontramos en una situación similar, luego de realizar la migración (aun estamos en etapa de pruebas), nos encontramos con que todos los departamentos en G2 son definidos como responsables académicas en G3.

Así quedaron los datos luego de la migración :

Departamento D 0001 INSTRUMENTAL BASICA
Departamento D 0006 MANEJO FORESTAL
Departamento D 0003 SOCIOLOGIA Y ECONOMIA
Facultad 0001 FACULTAD CIENCIAS FORESTALES
Facultad UA FORES Facultad de Ciencias Forestales

En este caso se repite la facultad porque se definió con otro nombre y código en la BD de g3 que ya tenia datos y por eso esta duplicado (eso ya vimos como solucionarlo a partir de este hilo). Pero en nuestro casos nos gustaría unificar todos los departamentos en una única Responsable académica, es decir en vez de tener la estructura de arriba, que solo quedara una RA.

Facultad 0001 FACULTAD CIENCIAS FORESTALES

La pregunta concreta seria, como podemos unificar todos los departamentos en una única RA.

Desde ya muchas gracias!

La pregunta concreta seria, como podemos unificar todos los departamentos en una única RA.
1. Crear la Responsable Academica: Facultad 0001 FACULTAD CIENCIAS FORESTALES
  1. En todas las tablas donde estan algunas de las siguientes respopnsables academicas:
    Departamento D 0001 INSTRUMENTAL BASICA
    Departamento D 0006 MANEJO FORESTAL
    Departamento D 0003 SOCIOLOGIA Y ECONOMIA
    Facultad 0001 FACULTAD CIENCIAS FORESTALES
    Facultad UA FORES Facultad de Ciencias Forestales

Agregar un registro en cada tabla para la responsable academica del punto 1.

  1. Borrar todas los registros de la responsables academicas del punto 2.

Gracias por tu respuesta Alejandro!, te hago otra consulta. Habría forma de hacerlos antes de migrar? Es decir que no migre ningún departamento pero que todos los elementos relacionados a estos (docentes, materias,etc) queden asociados a esta Responsable académica ( 0001 FACULTAD CIENCIAS FORESTALES).

Muchas gracias!

Hacer algo similar a lo indicado en la Respuesta #3:

  1. Previo a la migración, dar de alta en G3 la responsable académica 0001=FACULTAD CIENCIAS FORESTALES

  2. En el archivo \02_Modulos\05_Tablas_Comunes\01_tablas_conversion.sql luego del "UPDATE mig._cnv_pk_departamentos ", en la linea 100 agregar:


-- Quitar la pk de la tabla para que permita ids duplicados para los departamentos de G2:
ALTER TABLE mig._cnv_pk_departamentos DROP CONSTRAINT IF EXISTS pk__cnv_pk_departamentos;

-- Setear id de Responsable Academica de G3 0001 en los departamentos de G2 a unificar:
UPDATE mig._cnv_pk_departamentos 
  SET migrar = 0,
      existe = 1,
      observaciones = 'Existe un departamento con el mismo codigo',   
      responsable_academica = <ID RESPONSABLE ACADEMICA 0001=FACULTAD CIENCIAS FORESTALES de G3>
 WHERE mig._cnv_pk_departamentos.tabla = 'sga_departamentos' 
       AND departamento IN (<CODIGOS DE DEPARTAMENTOS DE GUARANI 2 QUE SE UNIFICAN EN LA RA 0001>) ;

2

Hola Alejandro!

Muchas gracias por tu respuesta, corrí el script con la modificación que me enviaste pero me daba algunos errores, con los cual fui analizando y corrigiendo. Me gustaria pasarte las correciones y si es posible que me indiques si estas están bien o pueden romper otra cosa.

35_calendario_academico/02_sga_anios_academicos.sql

Error
ERROR: duplicate key value violates unique constraint “pk_sga_anios_academicos_ra”
Detail: Key (id_fecha, responsable_academica)=(24, 1) already exists.

Posible solucion : Agregar DISTINCT en el select linea 62


35_calendario_academico/08_sga_periodos_inscripcion_fechas.sql

Error
ERROR: duplicate key value violates unique constraint “pk_sga_periodos_inscripcion_entidad”
Detail: Key (periodo_insc, entidad)=(55, 2) already exists.

Posible solución : Agregar DISTINCT en el select linea 36


40_docentes/10_sga_docentes_ra

ERROR: duplicate key value violates unique constraint “pk_sga_docentes_ra”
Detail: Key (docente, responsable_academica)=(2, 1) already exists.

Posible solución linea 56 agregar control si ya existe el registro

AND NOT EXISTS(SELECT 1 FROM sga_docentes_ra WHERE docente = doc.docente AND responsable_academica = mdepto.responsable_academica);

86_encuestas/04_gde_habilitaciones

ERROR: duplicate key value violates unique constraint “pk_gde_responsables_academicas”
Detail: Key (habilitacion, responsable_academica)=(14, 1) already exists.

Posible solución : Agregar DISTINCT en el select linea 269

De nuevo muchas gracias por tu tiempo!

Si Luciano, eran los “efectos colaterales” de hacer este cambio. Me olvide de avisarte que ibas a tener esos problemas en los módulos siguientes donde se consultara esa tabla ya que se iban a recuperar registros duplicados, pero lo bueno que pudiste ir corrigiendolos.