De: PICCININNO, Graciela Rita
Enviado el: jueves, 13 de diciembre de 2012 01:26 p.m.
Para: ‘Nicolas Dominguez Florit’
CC: PROFUMO, Daniel Mario
Asunto: RE: Error en la Migración a Mapuche
Nicolás:
Buenas tardes. Te comento que la consulta fue realizada por el GDS mientras estuviste de viaje, la pantalla adjunta en el mail corresponde al foro. Al no obtener respuesta, se reenvió por esta vía. Te agradezco la recomendación, de todas formas.
Saludos cordiales.
Ing. Graciela R. Piccininno
Sección Base de Datos
Dpto. de Informática y Comunicaciones
Ministerio Público Fiscal.Procuración General de la Nación.
Av. Belgrano 909, 2° piso.
TEL: (+54 11) 4335-3281
int. : 3281
www.mpf.gov.ar
“Ayudemos a cuidar nuestro ambiente imprimiendo sólo lo necesario. Es una propuesta de la UFIMA.”
De: Nicolas Dominguez Florit [mailto:ndominguez@siu.edu.ar]
Enviado el: viernes, 07 de diciembre de 2012 05:30 p.m.
Para: PICCININNO, Graciela Rita
CC: PROFUMO, Daniel Mario
Asunto: Re: Error en la Migración a Mapuche
Hola Graciela, disculpas por la demora. Realmente tuvimos unos días complicados por viajes y sumado a que estuve dos días de licencia.
Te aconsejo canalizar las consultas por medio del GDS (Gestor De Solicitudes). Ya que si yo estoy de viaje otro consultor te puede responder.
Nos vamos a dejar como deber (por eso necesitamos que nos cargues un GDS) investigar un poco mas, ya que haciendo memoria este error ya le había ocurrido a la Universidad Nacional del Sur (los cuales también utilizan planta). Igualmente, al estar implementándose planta en Mapuche, seguramente tengamos un script especifico que los ayude a migrar de la estructura vieja a la nueva.
Por el momento te pido que comentes este índice (no afectaría en nada, ya que todavía planta no esta incluido en Mapuche).
Con respecto a lo de Licencias, ese error sale en todas las licencias que no tienen fecha de inicio. Por lo cual lo correcto es eliminarlas.
En resumen: Sigan avanzando sin este índice.
Saludos,
Nico.
Nicolás:
Estamos a la espera de una respuesta al error que te envié por el foro. No te adjunto un dump de los datos pero envié un ejemplo del error detectado. De todos modos hicimos la actualización en los datos de prueba según te lo menciono y avanzamos hasta el cambio 1910 donde tenemos registros generados por la aplicación Pampa con el número de licencia y el número de legajo y los demás campos en nulo o cero, por lo que da un error al actualizar la tabla dh05. Para esto vamos a eliminar los datos erróneos y seguir con la corrida.
Voy teniéndote al tanto a medida que avanzamos con la prueba. Quedo a la espera de tus comentarios.
Copio a continuación el último mensaje enviado en el tema anterior, que quedó pendiente:
Re:Error al Instalar Siu-Mapuche
« Respuesta #4 : noviembre 30, 2012, 03:10:16 pm »
Si, efectivamente tenés razón. Analizando más el caso, el tema viene por los datos que no tienen el nro_hist_p en cero, como me comentaste en el mail anterior, pero que alguna vez sufrieron cambios.
por ej, en nuestra base aparecen de la siguiente manera:
el primer registro hasta el 31/01/2009 debió ser , siguiendo la lógica de los registros únicos, que nunca tuvieron cambios
nro_planta;codc_uacad;fec_alta;fec_baja;nro_hist_p
42000002;“AA11”;“2005-04-01”;“9999-12-31”;0
Pero cuando se realiza un cambio de planta, el primer registro de la lista es el nuevo, y el siguiente es el viejo con cambios en la fec_baja y nro_hist_p:
nro_planta;cod_uacad;fec_alta;fec_baja;nro_hist_p
42000005;“AA11”;“2009-02-01”;“9999-12-31”;42000002
42000002;“AA11”;“2005-04-01”;“2009-01-31”;42000002
Esta actualización la realiza el Pampa de esa manera, por lo que esos casos dan y seguirán dando duplicados a medida que se den más cambios. Entiendo que el nuevo registro debería tener un 0 en el campo nro_hist_p.
Pero se da a raiz de esto que te menciono, que si se vuelve a realizar un cambio en el registro
42000005;“AA11”;“2009-02-01”;“9999-12-31”;42000002
Entonces, la visualización en forma histórica es la siguiente, por ej:
42000008;“AA11”;“2012-02-01”;“9999-12-31”;42000002
42000005;“AA11”;“2009-02-01”;“2012-01-31”;42000002
42000002;“AA11”;“2005-04-01”;“2009-01-31”;42000002
Es decir, ante sucesivos cambios de registros que ya tuvieron un cambio anterior, se sigue arrastrando el nro_hist_p original, con lo que también tenemos casos que no se solucionarían con actualizar el campo a 0 (cero) dado que ya son bajas.
Para mi el update que se hace antes de generar el indice debería contemplar
nro_hist_p = 0
ó
nro_hist_p <> nro_planta
Saludos
Graciela