Preinscripcion G2 V291 - unica BD psql

Estimados.

Por ahí ya salio publicado, pero no lo encontré. :slight_smile:

Tengo entendido, que se puede armar una única base postgres (preinsc), y exportar de “n” BD informix a esta, los datos necesario para prescripción. Me podrían confirmar si estoy en lo correcto? Mucha gracias.

versión G2: 2.9.1

Saludos

¡Si se puede! Fijate en la wiki, específicamente donde se menciona Definición de alias de acceso.

Hola Emilse

Estas segura?

Si se desea utilizar una misma instalación de Preinscripción como front-end de varias Unidades Académicas, cada una con su propia base de datos y personalizaciones, se debe seguir el proceso autodocumentado en el archivo, del cual presentamos a continuación un ejemplo:

Emilio

¡Si Emilio! Refiere a las bases de Gestión, vean también la definición de los bloques de acceso en el archivo config.php. Quedó un poco confuso tal vez porque replicamos la documentación de G3 que es similar en este punto.
Cualquier duda que tengan vayan avisandonos; ya hay un par de instituciones que lo están utilizando así y otras probándolo.

A ver, no es un solo sitio para varias bases psql (preinsc), sino, donde me esta dando error es cuando exportas los datos - operación ifz00030 - (a partir de la segunda BD IFMX G2, la primera de diez) El esquema seria “n” BD G2-V291 (IFMX) a una sola BD psql (prescripción). Por ahí no estoy haciendo algo.

Saludos

Andres

Buen día Andres, ¿qué error tienen?

buen día . Adjunto


error mug_depto_partidos preinsc.png

error mug_depto_partidos preinsc.png

Andres, el problema está en la verificación que hace luego de migrar los partidos/departamentos.

Estos datos que estas migrando es de una 2da/3er/… Base de Guarani 2 que estas pasando datos a la unica base de preinscripción, no?

Porque lo que se hace luego de exportar los datos es verificar que la cantidad de datos de cada tabla que se exporta sea igual tanto en la tabla del módulo de preinscripción como en la tabla de la base de Guarani.

El problema seguaramente se debe a que ya había otros departamentos/partidos en la bsae de preinscripción de una migración anterior que no existen en la base actual de Guarani desde la cual estas exportando los datos, y por ello el error.

Quizas este demas este control en este caso, ya que los datos de localidades/provincias/paises/departamentos no dependen de la unidad academica.
Igualmente hay que tener cuidado, porque un alumno podria elegir al preinscribirse en una carrera de la unidad academica 1 una localidad que no exista en esta base de Guarani 2 donde se oferta esa carrera, y luego cuando se importe esa preinscripcion y todos los datos censales que se le solicitó al alumno va a fallar porque es localidad no existe en esa base, sino existia en alguna de las otras bases de Guarani 2.

Con lo cual, para poder unificar varias bases de Guarani 2 en una única base de Preinscripción, deberian ver que las bases de Guarani 2 tengan las mismas localidades (paises, provincias/deptos, codigos postales…), lo mismo con los datos de titulos secundarios, etc.

Si queres solucionar el problema podes comentar esa verificacion par que te deje continuar:
Libreria: siu_interfaces.pbl
Ventana: w_interface_guarani_preinscripcion
Evento: ue_exportar_localidades
Comentar el siguiente codigo:
Lineas 321 y 322 donde da el mensje y hace el return que corta el proceso. Agregar el mensaje y continuar:

ll_loop = ds_prein_mug_dptos_partidos.Update ()

if ll_loop = -1 then
	mensaje_usuario.text = mensaje_usuario.text + ' - fallo en el envío'
	Return False
end if
ds_mug_dptos_partidos.reset()
ll_loop = ds_prein_mug_dptos_partidos.Retrieve()
if ll_loop <> ll_cantidad THEN

// mensaje_usuario.text = mensaje_usuario.text + ’ - fallo en el conteo de verificación’
// Return False
mensaje_usuario.text = mensaje_usuario.text + ’ - Existen diferencias en la cantidad de departamentos/partidos’
END IF
ds_prein_mug_dptos_partidos.reset()
mensaje_usuario.text = mensaje_usuario.text + ’ - Ok.’

Lo que podemos hacer es actualizar esos controles y solo ponerlos como advertencia pero que deje continuar exportando los datos que son comunes a diferentes instalaciones.

Hola Alejandro. si si eso ultimo me gusto. :slight_smile: Que deje exportar los datos comunes.

Estiamdos.

Se exportaron los datos. Ahora hay algunas cuestiones que surgieron con las pruebas, por donde las gestiono por aquí o por gds ?

envio algo en adjunto.

preinsc 291


preins_291.rar (275 KB)

Hola Andrés,

Respondo a las consultas del adjunto:

1. Cuando existe la persona en sga_personas muestra los datos cargados recintemente no los existntes (creo que debería mostrar los existente para poder comparar).
Respuesta: Acá no se chequea la tabla ‘sga_personas’, sino ‘sga_preinscripcion’, que es donde se almacenan entre otras cosas los datos de registro y autenticación. Por eso el mensaje dice “Existe un usuario registrado con tu número de documento…”. La razón de ser de este control (y el mensaje) es no multiplicar la cantidad de usuarios de una persona, ya que solía pasar que por no ver el mail de alta creaban un nuevo usuario.

2. No muestra un mensaje luego de la generación del usuario (si el mail no fue enviado), solo muestra cuando detecta que envió el mail.
Respuesta: ¿Por qué no lo envía? ¿Por un error del servidor de correo? Con un servidor bien configurado no hemos experimentado problemas al respecto. En el panel de administración hay una operación para enviar un mail de prueba y chequear su correcto funcionamiento.

3. No levanta los datos en el caso de que el usuario exista en la base, de la tabla sga_personas.
Vale la respuesta 1.

4. En sede muestra en nombre de la base?
Respuesta: No, muestra el nombre de la sede. Corroborá si tu sede no se llama así. Este es la porción de SQL que obtiene el campo: “sga_sedes.nombre AS sede_nombre”

Cualquier otra consulta que no involucre datos privados, escribinos por acá. Si no, GDS!

Saludos,
Fernando

Hola Fernando

Punto 2

La conexión con el servidor de correo puede fallar por varios motivos inclusive estando bien configurado. Un problema de red no es tan infrecuente como para no considerarlo. Además no le aparece al administrador, le aparece al usuario que por primera vez utiliza este sistema por lo cual los mensajes deben ser claros.

Punto 4
Ver gds.

Emilio

Emilio,

Con respecto al punto 2, modifiqué el mensaje que se muestra luego del alta, dando la posibilidad de solicitar el reenvío de mail si no fue recibido. En la versión 2.9.2 hay otros puntos del sistema donde se da la posibilidad de reenviar el mail de alta, por ejemplo, cuando se intenta loguear sin haber autenticado la cuenta a través del link.

El punto 4 lo seguimos por GDS.