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