y… ya no sabría decirte con certeza jaja. Te digo mi configuración:
-cliente instalado por el instalador automático para la localización AR (bajo XP)
-base de datos de desarrollo creada por el instalador anterior
-base de datos de instalación creadas por mi usando los .sql que en el directorio data del instalación anterior y el sql para instalar sqlj. La base de datos la cree desde pgadmin especificándole enncoding UTF8 (que supongo que es el encoding default para todo; aunque probablemente NO para el enconding de las conexiones, aunque no creo que venga por ahi).
-use el mismo cliente tanto para la exportación como la instalación del componente (obviamente accediendo a distintas bases de datos)
-siempre acceso seleccionando el lenguaje AR
El tema es que cuando instale el componente de Juguetes hice exactamente lo mismo (bah, creo) y los nombres de los campos (y asumo que todo lo que sea strings) fue generado en UTF8 y también importado usando el mismo encoding (por ej, el campo “Organización” en la ventana de juguetes aparecía bien en las dos bases de datos). Ahora, mirando el install.xml de este componente (PSP01) esta claramente en UTF8 (e.d, la exportación es correcta; busca dentro de este archivo por ej “Organización”); así que el tema debe venir por la importación. Bien, porque la importación de Juguetes anduvo bien con respecto a UTF8, pero la importación del actual componente no, es medio raro; las únicas diferencias son básicamente que uno crea una vista sql, mientras que el otro una tabla; pero a nivel de metadatos son similares, por ej en las inserciones en AD_Field_trl los dos tiene “Organización” en correcto UTF8.
Lo unico que se ocurre para este comportamiento cuasi-aleatorio es: las librerías de Java de acceso archivos de texto, si no se le especifica cual es el encoding del archivo (o cual es el encodig por defecto), hace lo que muchos editores de texto: llevan a cabo un algoritmo que no es 100% seguro para “estimar” cual es el encoding (por ej, si comienza con los bytes “BOM”, obviamente es UTF8; si no, leen los primeros caracteres y si encuentra uno que NO puede pertenecer a UTF8, asumen que es otro enconding, etc etc; dicho sea de paso, no existe un algoritmo 100% seguro para esto). Obviamente, si este estimación falla va todo mal…
Estoy casi seguro que si agarro el install.xml y le pongo un “BOM” adelante (por ej, con notepad++) y vuelvo a instalar el componente, va a andar bien, ya que java se va a dar cuenta que está en UTF8 (pero bueno… tengo que crear ooooootra base de datos). Después lo testeo y me saco la duda.
En cuanto al tema del preinstall.sql, el tema creo que viene por otro lado y aca creo que si depende de postgress más que de libertya (aunque seguro que desde libertya se puede subsanar); en particular de donde esta instalado el servidor. Si vos miras el preinstall.sql de Juguetes y el de este componente vas a ver que lo unico que cambia es que una crea una tabla y el otro una vista. Los dos archivos usan a veces LF y otras CR,LF como separador de lineas (por lo que vi, usan LF para separarar las columnas y cosas por el estilo y CRLF para separar sentencias CREATE completas). Asi por ej, el create de Juguetes comienza (viendolo en notepad++ mostrando los finales de linea)
[LF]
m_juguetes_id integer NOT NULL, etc etc etc
y el de la vista como
SELECT plv.ad_client_id
En los casos usa LF como separador, pero en el último, si un elimina el LF (o no lo considera como un separador que creo que es lo que pasa cuando postgress esta instalado bajo Windows) se cae en un error sintáctico ya que AS queda pegado al SELECT (e.d “CREATE VIEW v_product_not_in_plv ASSELECT”). Pero en el caso de la tabla queda “CREATE TABLE M_Juguetes(m_juguetes_id integer NOT NULL” todo junto, lo cual NO es un error sintáctico ( el “(” justo despuesde M_Juguetes sirve como separador, de igual manera que las comas sirven después como separador de columnas dentro del create). E.d, es algo que que debe pasar solo cuando se crea una vista y solo cuando el server está bajo Windows. Creo que esto no es un error relativo a UFT8 (UTF8 incluye tanto a LF como a CR), si no que se están generando algunas separaciones con LF y otras con CRLF. Yo lo solucione sacando el LF y poniendo un espacio en su lugar, como esta en dentro del PSP01.zip (obviamente me quedo un create view larguisimo de una sola linea); seguro que también hubiese andado si reemplazaba el LF por CRLF (lo que no se es si esto ultimo hubiese traído problemas si lo hubiese instalado en servidor corriendo bajo Linux….)
