Error con tipo de dato en migracion

El Pentaho corta la ejecución del trabajo ifx2pg con distintos errores en distintas tablas:

– Batch entry 0 INSERT INTO mig.sga_fec_insc_cur (anio_academico, periodo_lectivo, orden, nombre, fecha_inicio, fecha_fin, --fecha_tope_bajas) VALUES ( 1987, 0, 1, inscripción de materias anuale, 1987-03-23 00:00:00.000000 -02:00:00, 1988-03-12 --00:00:00.000000 -02:00:00, 1988-03-12 00:00:00.000000 -02:00:00)
–ERROR: el valor es demasiado largo para el tipo character varying(30)
Este error aparece con las siguientes tablas:
sga_fec_insc_cur
sga_exep_insc_llam
sga_insc_exa_bajas
sga_llamados_mesa
sga_perdidas_regul

Este error: – ERROR: el valor null para la columna «legajo» viola la restricción not null aparece en la tabla sga_plan_no_hall

Este error – Error updating batch
– org.pentaho.di.core.database.Database.emptyAndCommit(Database.java:1471) en sga_causa_perd_reg.

Si le ponemos que no migre estas tablas el trabajo continúa, pero necesitamos migrarlas por lo que queremos saber como solucionamos estos errores.

Gracias
Lucía

Hola a todos,
estamos necesitando alguna respuesta a este problema, ya que no podemos seguir con la migracion a 3. Nos da el error de tipo de dato. Probamos cambiando el encoding de la base a latin1, pero da el mismo error.
¿Alguna pista para poder seguir?
Saludos.

Marcela Vera
UTN Regional Santa Fe

Hola,
para el primer error, --ERROR: el valor es demasiado largo para el tipo character varying(30)
En informix el tamaño de ese campo es el mismo? porque la estructura de la tabla de informix debe ser una copia exacta en postgres…

para el segundo error, – ERROR: el valor null para la columna «legajo» viola la restricción not null aparece en la tabla sga_plan_no_hall
Se dieron casos que a las cadenas vacias los toma como null (de todas formas fijate si en informix tenes legajos como cadenas vacias) si ese el caso, hay un parametro que deberías chequear si esta activado en Y, desde el kettle, haces ctrl+alt+P se te abre el kettle properties y en KETTLE_EMPTY_STRING_DIFFERS_FROM_NULL ponele el valor Y

y para el tercer error podrías dar mas detalles?

Saludos!
Marcelo

Hola,
la BD se creo CON LAS TAREAS QUE BAJAMOS DEL SITIO PARA GUARANI 3 ALPHA. En guarani esta tabla tiene el siguiente script :
CREATE TABLE sga_fec_insc_cur (
ANIO_ACADEMICO integer NOT NULL,
PERIODO_LECTIVO varchar(20) NOT NULL,
ORDEN integer NOT NULL,
NOMBRE varchar(30),
FECHA_INICIO datetime year to second NOT NULL,
FECHA_FIN datetime year to second NOT NULL,
FECHA_TOPE_BAJAS datetime year to second NOT NULL
);
Por lo que supuestamente tiene los mismos campos… mi pregunta es ¿No es problema del encoding? me llama la atencion porque da estos errores en aquellas tablas que tienen campos con espacios o algun caracter no comun.

Para el segundo caso, hice en informix un:
select * from sga_plan_no_hall where legajo is null; – y no retorna datos, por lo que no hay legajos “nulos”, si hay para cuando hago una busqueda :
select * from sga_plan_no_hall where legajo = ‘’; – ahi si devuelve datos
En cuanto a como arreglarlo, no entiendo realmente lo que me decis, trabajo desde Pentaho para las tareas, y para ver las BD en Postgres lo hago desde el PgAdmin III ¿en cual de las herramientas cambio esta parametro?

Del tercer error, eso es lo que nos da, no tenemos mas detalles, como te dije, las tareas las corremos desde Pentaho, y esto es lo que nos aparece en la pestaña de errores.

Te comento que cuando entro al PgAdmin, me da un mensaje respecto a la BD SIU que es donde tenemos todos los esquemas, que es el siguiente:

"The database SIU is created to store data using the SQL_ASCII encoding. This encoding is defined for 7 bit characters only; the meaning of characters with the 8th bit set (non-ASCII characters 127-255) is not defined. Consequently, it is not possible for the server to convert the data to other encodings.
If you’re storing non-ASCII data in the database, you’re strongly encouraged to use a proper database encoding representing your locale character set to take benefit from the automatic conversion to different client encodings when needed. If you store non-ASCII data in an SQL_ASCII database, you may encounter weird characters written to or read from the database, caused by code conversion problems. This may cause you a lot of headache when accessing the database using different client programs and drivers.
For most installations, Unicode (UTF8) encoding will provide the most flexible capabilities. "

¿puede ser que el encoding no este trayendo problemas?
Espero sus respuesta para seguir avanzando.
Saludos.

Marcela Vera