Hola:
Estamos haciendo la migración de G2 a G3 de una base de la facultad de humanidades, pero tenemos unas consideraciones para hacer, les explico.
Hace dos años se migro de esta misma base la “estructura”, planes de estudio, algunas personas, docentes, actividades, etc, pero no se migro, alumnos, historia académica. Esto se tuvo que hacer asi por un tema que se necesitaba implementar si o si en las sedes de la facultad y quedar Comodoro para mas adelantes.
Ahora, mas o menos que script debería saltar y cuales correr? también tengo un inconveniente ya que me dijeron que en este tiempo crearon una nueva versión de un plan que no esta en G3, aca seria mejor cargarlo por gestión con los mismos códigos y nombres, o el script de planes lo puede cargar?
Esto por ahora, Gracias por todo.
Desde esa primera migración a hoy, por lo que comentas siguieron trabajando con Guarani 2, no?
Se migró el calendario académico, comisiones y mesas de examen en aquel momento o hay que migrar todo hoy?
Hay alumnos que no estan en Guarani 3 y otros que si estan y ya tienen historia académica en Guarani 3 desde aquel momento que lo implementaron, no?
Respecto a la nueva version del plan de estudios, creo lo mejor es crearlo desde Guarani 3. Luego cuando se pasen los datos de Guarani 2 al esquema mig de Guarani 3, lo que se puede hacer en la tabla de conversion de versiones de planes de estudios (mig._cnv_pk_planes_versiones) es cambiar el dato “plan_version” de cada version de plan por el id que tiene en la tabla de Guarani 3 (sga_planes_versiones) y en principio no deberían migrar el módulo de Propuestas y Planes de estudios. Lo mismo habría que hacer con la tabla de conversion de propuestas y planes de estudios.
Hola Alejandro, gracias por la ayuda. Te cuento, se migro estructura, planes, calendario, actividades, escalas de notas, no se migro alumnos, personas, ni comisiones.
Tengo en este G3, algunos alumnos que están en G3, por un tema que se cambiaron de ubicación, cambiaron de propuesta a otra responsable, ahora en prueba, veo que encontro algunas personas y las puso para no migrar.
Por ahora voy a seguir como me decís, cargando la nueva versión del plan y de ahi vemos que hace.
Saludos
Asi es, si al pasar los datos de personas a la tabla de conversion en el esquema mig, busca si existe ya una persona con el mismo número de documento (pais + tipo + nro de documento) y si lo encuentra lo marca como que existe y no lo migra. Ahi tambien fijate que en esa tabla (mig._cnv_pk_personas) podes definir si actualizas sus datos censales, solo si el ultimo dato censal es mas reciente que el que esta en Guarani 3 o si no migras sus datos censales).
Lo mismo va a pasar con los docentes, si detecta que ya existe el registro en al tabla de docentes (tabla mig._cnv_pk_docentes). Alli estan los camos “existe” ( indicando si existe ya un docente con ese nro de legajo o no) y el campo “migrar_docente” que se setea en 0 si queres que no se migre porque ya existe.
Recorda que no debes migrar actividades, propuestas ni planes de estudios. Tampoco el calendario académico porque ya lo migraron (años academicos, periodos lectivos, comisiones, turnos de examen, llamados, mesas de examen).
El tema aca es que en el esquema mig , en las tablas de conversion de pk de aquellos datos que ya migraste vas a tener que actualizar el id que identifica ese dato en G3.
Por ejemplo, al pasar los datos de las comisiones al esquema mig, la tabla “_cnv_pk_comisiones” se llenó con las comisiones definidas en Guarani 2. Pero alli el dato “comision” debería cambiarse por el id de comision que corresponde a esa comision en la tabla sga_comisiones de Guarani 3.
Esto es, porque aunque no se migre las comisiones porque ya fueron migradas antes, hay scripts de migracion por ejemplo del módulo de historia cademica que hacen join con esta tabla de conversion, con lo cual si esa tabla no esta reflejando el dato correcto que esta en Guarani 3 quedarían mal registradas las actas y equivalencias.
Alejandro:
En la migración anterior,se migro el calendario, pero a esa fecha, después se siguio cargando en G2, digamos, que nos falta la carga de los últimos años. Aca, el script lo reconoce o hay que cargarlo a mano en G3 tambien?
Y tambien, hay una propuesta que no esta en G3, se cargo unicamente en G2, Seria mejor cargarla a mano?
Saludos
En la migración anterior,se migro el calendario, pero a esa fecha, después se siguio cargando en G2, digamos, que nos falta la carga de los últimos años. Aca, el script lo reconoce o hay que cargarlo a mano en G3 tambien?Entonces van a tener que migrar lo que se cargó en G2 a partir de esa fecha y no migrar lo que ya fue migrado. El script de migración del calendario no verifica si ya existe el dato en Guarani 3, con lo cual van a tener que indicar para cada tabla de turnos, llamados, mesas de examen, periodos lectivos y comisiones a que dato de G3 corresponde (de lo ya migrado en aquel momento). Para esto tendran que actualizar los ids de las tablas de conversion de pk que corresponden a estas tablas, indicar que no se migren y luego en el script de migración contemplar esto, es decir migrar solo lo nuevo que no fue migrado la vez pasada. Deben agregar el campo "migrar" con valor defecto 1, pero cuando indiquen que por ejemplo ese periodo lectivo ya existe cambien el id de "periodo_lectivo" y 0 en el campo "migrar". Y en el script que migra agregar la condicion de migrar solo los periodos lectivos que tienen el dato migrar = 1.
Asi es como esta solucionado por ejemplo en la tabla de personas (mig._cnv_pk_personas)
Y tambien, hay una propuesta que no esta en G3, se cargo unicamente en G2, Seria mejor cargarla a mano?Si es una sola propuesta, carguenla por el sistema, luego lo que deben hacer es agregar un registro en las tablas de propuestas, planes y versiones de plan con el id de cada tabla de G3 (mig._cnv_pk_propuestas, mig._cnv_pk_planes, mig._cnv_pk_planes_versiones). Con esto no deben migrar el modulo de planes de estudios.