buenas, como están?
les comento que cambiamos el servidor y actualizamos a la versión 3.4.3
como el servidor quedo con la misma IP y el postgres con los mismos accesos.
lo que hice fue bajar el escritorio de 3.4 y copiarle el POSTGRES.INI del escritorio anterior (que estaba funcionando en 3.1.2)
y no funciona… da error de “la tabla rrhhini no puede ser abierta”.
desde la PC donde esta instalado el escritorio si tengo acceso a la base por PGAdmin.
el Driver de PostgreSQL es el 7.02 del 15/12/2003.
Buenas, seguí investigando.
Lo último que hice fue actualizar el servidor de postgres, y los locales del debian, que ahora están configurados en es_AR.
ahora las consultas están funcionando bien salvo en esta PC que me sigue manteniendo el problema.
como si la configuración del windows, es incompatible con la del servidor y sigue teniendo ese conflicto de caracteres.
Hola!
te paso los datos de como estan configurados los ambientes.
El servidor tiene LOCALE = “es_AR”
El servidor postgres es un 9.6 y quedo configurado con COLLATE y CTYPE en “es_AR”
las bases del servidor “postgres” y “template0” están con encoding “LATIN1”
por el lado del cliente Windows 7 (probe conectarme de varios windows y todos dan el mismo error).
si abro una ventana de consola y ejecuto el psql, me da error “psql: FATAL: la conversión entre WIN1252 y LATIN1 no está soportada”
ahora, desde la consola, si yo seteo previamente la variable:
set PGCLIENTENCODING=ISO8859-1
entonces después si puedo conectarme al servidor por PSQL en la consola de windows.
no se si estos datos te sirven, por lo que entiendo,
me estaría faltando que este PGCLIENTENCODING se lo pueda pasar directamente al windows (encontre que es el 1252).
Recién probe desde la linea de comandos de windows hacer el PGCLIENTENCODING, y luego ejecutar el mapuche.exe del escritorio pero sigo sin acceder con el mismo error en la lectura de la tabla rrhhini.
después de setear los parametros como vos me dijiste, me conecte por psql al servidor.
se conecta pero deja este cartel:
WARNING: Console code page (65001) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference page “Notes for Windows users” for details.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
cuando me intento conectar al escritorio, sigue dando el error que no puede leer la tabla.
antes que nada, volve el cambio de chcp atras, abri la consola y escribí chcp 1252.
Por otro lado te adjunto el archivo postgre.ini para que configures mapuche con los datos de conexión. Editalo y modifica los datos haciendo referencia a tu conexión . Por otro lado comproba que el usuario que estas utilizando exista y tenga permisos.
Recorda de cambiarle la extensión TXT por INI al archivo respetando las mayúsculas.
Hola Dario, nosotros estamos migrando a la versión 3.4.3, cambiando de plataforma Windows a Debian, tuvimos muchos problemas con la codificación, establecimos los locales es_AR (ISO-8859-1) para el sistema operativo y las bases de datos, templates, etc. (todo a ISO-8859-1 / LATIN1), lo extraño es que si dejamos que la codificación de la base de Mapuche sea SQL_ASCII, pgadmin3 directamente no muestra ningún campo que contenga caracteres extraños, acentos, etc., por tal motivo establecimos la base Mapuche a LATIN1. Aún no comprendemos porque se sigue usando SQL_ASCII para la base de Mapuche, la base de toba tiene codificación LATIN1 y en las ultimas versiones de Mapuche es requerido establecer en PHP la codificación ISO-8859-1. Lo que nos lleva a pensar y según todas las pruebas que hicimos, que no debería existir problemas en que la Base de Mapuche sea establecida en LATIN1.
Estamos por hacer pruebas con el Mapuche Escritorio, ni bien tengamos resultados les comentaremos de la experiencia. Mientras podrían probar establecer la base de Mapuche en LATIN1 y correr Escritorio nuevamente, tal vez sea solo una cuestión de codificación.
Una cuestión con la codificación SQL_ASCII: La codificación SQL_ASCII básicamente significa que no hay codificación, y simplemente almacena los bytes que le arrojas. (extraído de https://www.endpoint.com/blog/2017/07/21/postgres-migrating-sqlascii-to-utf-8) Esto significa que puedes almacenar en la base cualquier datos con diferentes codificaciones, puedes introducir un carácter chino, un carácter latín, y muchos otros caracteres sin problema, el inconveniente se presenta cuando trabajas con un sistema que reconoce un solo tipo de codificación, se generan errores como: ERROR: secuencia de bytes no válida para codificación «UTF8»: 0xfc., etc.
Hola Marcelo, gracias por tu colaboración.
como tengo 2 bases en el servidor de postgres, pude probar lo que me dijiste.
Modifique el encoding de la base:
en LATIN1 (update pg_database set encoding = 8 where datname = ‘xxx’
Pero el escritorio sigue dando el mismo problema: “La tabla “rrhhini” no puede ser abierta. File Not Found (2)”
si le cambio el encoding a UTF-8, ahí da error, pero cambia.
UPDATE pg_database SET encoding = 6 WHERE datname = ‘xxx’;
con enconding utf-8 la base da error: “La tabla “puestos” no puede ser abierta. client enconding mismatch (HY019)”
Hola Darío, el problema de rrhhini se soluciona descomentando la siguiente línea en postgresql.conf search_path, cambias el valor '“$user”,public por ‘“mapuche”,public’. No olvides reiniciar el server. Me avisas si lograste hacer funcionar. Saludos
el problema “la tabla rrhhini no puede ser abierta” Lo solucionan desde el pgadmin, no es necesario modificar el conf.
Para solucionarlo deben abrir el pgadmin, ir a Login Roles, buscar el usuario con el que se conectan a mapuche escritorio y presionar botón derecho, luego Propiedades, en la ventana que se abre buscan la solapa Variables y ahí se fijan si tienen en agregada la variable search_path, si no es asi la agregan:
Variable Name: Search_path
Variable Value: mapuche, public
Presionan Agregar, luego aceptan o cancelan
De esta forma ya les deberia andar sin modificar el archivo conf de postgres.
