Error al Instalar Siu-Mapuche

SIU-Mapuche Técnicos Mapuche
1

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.

Estimados:
Qué tal? Estuvimos haciendo una prueba para instalar el Mapuche habiendo solucionado previamente el tema de la versión, por lo que actualizamos la base a 5.15.
Al ejecutar el instalador nos dio un error en la conversión de los datos del Pampa, que copio a continuación:

Problemas ejecutando el cambio #1883.

SQLSTATE[23505]: Unique violation: 7 ERROR: could not create unique index “ix_dp20_key_nro_hist_p_codc_uacad” DETAIL: Table contains duplicated values.

Revisando el error que da la instalación, se produce cuando quiere crear el siguiente índice

create unique index “ix_dp20_key_nro_hist_p_codc_uacad” on pampa.dp20 using btree (nro_hist_p,codc_uacad);

Estamos usando datos obtenidos de producción para hacer la prueba. Al revisar la tabla pampa.dp20

select nro_hist_p,codc_uacad,count()
from pampa.dp20
group by 1,2
having count() > 1

Hay 702 casos que tienen duplicados y los de mayor ocurrencia tienen el número de planta histórica en cero, pero también hay casos que no.
Recordando que la parte de planta todavía no está completa en Mapuche, quería consultarles como avanzar dada esta situación, dado que vuelvo a reiterar que la base de Pampa a convertir contiene los datos de producción.
Saludos.

Graciela Piccininno

2

Hola Graciela, ese cambio en el paso inmediatamente anterior a crear el índice, actualiza el campo nro_hist_p. Por lo cual los casos de cero no te tendrían que afectar ya que la actualización se fija justamente eso. Te paso lo que hace el cambio #1883:

ALTER TABLE mapuche.dp20 ADD COLUMN desc_comen character varying(500); COMMENT ON COLUMN mapuche.dp20.desc_comen IS 'Comentario'; UPDATE mapuche.dp20 dp20 SET desc_comen = (SELECT desc_comen FROM mapuche.dp21 dp21 WHERE dp20.nro_planta=dp21.nro_planta); ------ UPDATE mapuche.dp20 SET nro_hist_p = nro_planta WHERE nro_hist_p is null or nro_hist_p =0; CREATE UNIQUE INDEX ix_dp20_key_nro_hist_p_codc_uacad ON mapuche.dp20 USING btree(nro_hist_p, codc_uacad); ------ ALTER TABLE mapuche.dp20 ALTER COLUMN fec_alta SET NOT NULL; ALTER TABLE mapuche.dp20 ALTER COLUMN codc_uacad SET NOT NULL; ALTER TABLE mapuche.dp20 ALTER COLUMN codc_categ SET NOT NULL;

Creo que los casos en que te esta fallando son justamente los que son distinto de cero. Cuantos casos son? hay que evaluar si tienen sentido esos registros o son datos basura.
Por favor pasanos la cantidad y si estos registros tienen sentido o son “basura” que quedo en la tabla.

Saludos,
Nico.

3

Nico:
Entiendo lo que me comentás pero sería así si el índice unico que creara después fuera por nro_planta, nro_hist_p pero no es el caso. Te mando el lote de datos que daría problemas después de hacer el update de nro_hist_p = nro_planta dado que el campo codc_uacad como podrás ver tiene duplicados, y no son pocos los casos.
Muchas gracias y saludos.

Graciela

pampa.dp20.txt (92.5 KB)

4

Graciela, la tabla dp20 tiene una clave única por nro_planta. Cuando se ejecuta el update transforma todos los nro_hist_p en cero a nro_planta.
Luego al crear el índice se utilizan dos campos. La unicidad es por la dupla nro_hist_p, codc_uacad.
Te pido por favor que me envies un dump (formato plano con insert) la tabla dp20 completa a mi mail institucional para que pueda evaluar los motivos por los cuales se rompe la actualización.
Con los datos que me enviaste no se rompe ya que al estar todos los nro_hist_p en cero, el update hace que este tome lo que tiene la clave unica por lo cual ya pase a ser unico por si solo sin necesitar del campo codc_uacad.

Saludos,
Nico.

5

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