Hola equipo de TOBA … les comento que estamos realizando un desarrollo en SIU-Toba_v2.5.2, con postgresql 9.1 y estamos teniendo problemas con el encoding de las bases de datos.
Paso a detallar como tenemos en la instancia de desarrollo y en produccion
En desarrollo tenemos la base propia con el encoding LATIN1 y la base toba con UTF8
En produccion nos queda la base propia en UTF8 (y en el archivo bases.ini tenemos los schemas tanto public como toba en LATIN1).
El tema es que en la instancia de desarrollo tenemos listados en los que se visualizan datos y en produccion, los mismos listados no estan mostrando ningun dato, cuando sabemos que existen.
Hemos realizado la prueba de cambiar en la instancia de produccion, el encoding de UTF8 a LATIN1 y tanto en el menú de la aplicacion como en el entorno de toba_usuarios se visualizan los acentos en forma de caracteres especiales… y el listado puede generarse en forma parcial, ya que en algunas columnas todavia no se visualizan datos.
En el archivo proyectos.ini que utilizamos para realizar el empaquetado, tenemos en la seccion de base:
[base]
fuente = myexport ;Dejar valor por defecto
nombre = myexport ;Corresponde al nombre de la BD
schema = public ;Corresponde al esquema de la BD
encoding = LATIN1 ;Corresponde al encoding de la BD
usuario_postgres = myexport ;Corresponde al rol de inicio de sesión (usuario) a la BD
rol_postgres = dba ;Corresponde al nombre del grupo de roles al que pertenecerá el rol myexport
estructura = sql/estructura.sql ;URL que indica donde se encuentra el archivo que contiene la estructura de la BD
languages = plpgsql
grupos_datos = myexport
El archivo estructura.sql fue creado como archivo plano, solo estructura, LATIN1.
Quedamos a la espera de su respuesta, de que puede ser que estamos realizando mal.
Saludos
por que tienen esa diferencia entre la bd de negocio de desarrollo y de produccion?.. todo deberia estar con UTF-8 (en cluster) y LATIN1 (en bases.ini). De otra manera, cuando empiecen a pasar datos de una a otra, pueden llegar a tener problemas si no fijan correctamente el client_encoding en las SQL. Aqui el inconveniente a mi parecer lo tienen en desarrollo, no en produccion, es ese el lugar que yo cambiaria.
El tema es que en la instancia de desarrollo tenemos listados en los que se visualizan datos y en produccion, los mismos listados no estan mostrando ningun dato, cuando sabemos que existen.
De donde salieron esos datos?.. hicieron una exportacion de produccion y la importaron en desarrollo?.
Hay alguna diferencia de codigo entre produccion y desarrollo o estan corriendo exactamente lo mismo?.
El listado que mencionas, es un pdf, una generacion por pantalla, como se exporta?
Hemos realizado la prueba de cambiar en la instancia de produccion, el encoding de UTF8 a LATIN1 y tanto en el menú de la aplicacion como en el entorno de toba_usuarios se visualizan los acentos en forma de caracteres especiales.... y el listado puede generarse en forma parcial, ya que en algunas columnas todavia no se visualizan datos.
Aca estan haciendo macanas, si ya estaba en UTF-8 no conviene cambiar el encoding a LATIN1, mas cuando el motor de bd puede hacer la conversion automaticamente en runtime. Esas conversiones forzadas terminan generando mas inconvenientes que beneficios, la base tiene que quedar como cuando se crea en el cluster… el resto se maneja desde la conexion.
Por otro lado, si con eso consiguen recuperar alguno de los datos, entonces el inconveniente esta en algun otro lugar, te hago unas consultas (como si te hubiera preguntado poco hasta aca :p) :
Como se cargaron esos datos?.. via SQL, via sistema, via manejador de bd?
Como se recuperan esos datos para mostrar en el listado?.. via una conexion de toba, via una conexion manual, via jasper?. Quien hace la conexion a la bd?.