[Javier Ader]

Que tal Federico. Al final no tuve tiempo de probarlo desde libertya, pero no entiendo bien lo que me estas queriendo decir, en particular el tema de que no resuelve las referencias. Yo lo que probe fue, desde pgAdmin, crear un función que creaba una tabla y un vista y luego la ejecute; esta ejecución creó la tabla y la vista lo más bien.
En tiempo de creación de una función postgres debe hacer algún tipo de parsing, pero no hace chequeo de referencias; la siguiente función se crea lo más bien

Code:

set search_path to libertya;

CREATE OR REPLACE FUNCTION fEjFunction2 () RETURNS CHARACTER VARYING AS $$
BEGIN

set search_path to libertya;
create table ejTabla2(
id integer not null,
name character varying(40)

);
— insert en la tabla creada justo antes
insert into ejTabla2(id,name) values (10,’nombre’);
create view ejView2 as select * from ad_client;

RETURN ”;
END;
$$ LANGUAGE ‘plpgsql’;

Fijate que el insert hace referencia a una tabla inexistente en tiempo de creación de la función (tiempo de parsing). La ejecución de esa función (select * from fEjFunction2 (); ) crea la tabla y agrega la fila normalmente.
Incluso creando un función que haga referencia a una tabla no va a existir tiempo de ejecución no tira problemas de parsing.Ej

Code:

set search_path to libertya;

CREATE OR REPLACE FUNCTION fEjFunction3 () RETURNS CHARACTER VARYING AS $$
BEGIN

— insert en la tabla creada justo antes
insert into ejTablaINEXISTENTE(id,name) values (10,’nombre’);

RETURN ”;
END;
$$ LANGUAGE ‘plpgsql’;

La creación de la función no tira errror; obviamente si lo hará la ejecución (ERROR: relation “ejtablainexistente” does not exist)
En cualquier caso yo proponía esta forma solo para ejecutar el preinstall.sql o como un método general para aquellos casos en el que sería bueno ejecutar múltiples sentencias; todo lo demás lo veo correcto que sea haga via los xmls en el caso de los componentes (no creo que tenga tanta importancia la performance en este caso; nadie instala componentes todo el tiempo).

[Javier Ader]

Si miras en las variables de ambiente, aparece el campo para ingresos brutos? [la entrada es IIBB, pero solo te debería aparecer cuando estes mirando una entidad comercial que sepás de antemano que tiene asociado un numero de ingresos brutos; por ver cuales podes hacer “select * from libertya.c_bpartner where IIBB is not null” ) Por lo que vi antes, algún campo cambio entre las versiones (al menos el número de secuencia para ingresos brutos cambio de 100 a 90). No se como habras solucionado el campo del CUIT pero tal vez lo que esta pasando es que el campo de ingresos brutos quedo “en la misma” linea que el campo que le precede y esto hace que en realidad este pero simplemente no lo visualices (queda muuuy a la derecha). Yo lo tengo en la misma linea que “TaxId” que es el numero de cuit; este ultimo TaxId NO esta en la misma linea que el anterior (que es la categoría de IVA).
También podrías mirar la longitud del campo (tal vez tenga un numero raro)y la columna “displaylogic”.
Te paso la siguiente consulta que tiene los datos relevante para lo que digo y su resultado en mi base de datos (que proviene de una migración)

Code:

set search_path to libertya;

select f.seqno, f.issameline, f.isactive, f.isdisplayed, f.displaylength , f.name, t.name
from ad_field f inner join ad_tab t on (f.ad_tab_id = t.ad_tab_id)
where t.ad_tab_id = 220 and f.isdisplayed = ‘Y’
order by f.seqno asc

seqno;f.issameline;f.isactive; f.isdisplayed;f.displaylength;f.name;t.name
10;”N”;”Y”;”Y”;14;”Client”;”Business Partner”
20;”Y”;”Y”;”Y”;14;”Organization”;”Business Partner”
30;”N”;”Y”;”Y”;11;”Search Key”;”Business Partner”
40;”N”;”Y”;”Y”;60;”Name”;”Business Partner”
50;”N”;”Y”;”Y”;60;”Name 2″;”Business Partner”
60;”N”;”Y”;”Y”;60;”Description”;”Business Partner”
70;”N”;”Y”;”Y”;4;”Categoría de IVA”;”Business Partner”
80;”N”;”Y”;”Y”;20;”Tax ID”;”Business Partner”
90;”Y”;”Y”;”Y”;14;”Número de Ingresos Brutos”;”Business Partner”
100;”N”;”Y”;”Y”;1;”Active”;”Business Partner”
110;”N”;”Y”;”Y”;14;”Business Partner Group”;”Business Partner”
120;”N”;”Y”;”Y”;11;”URL”;”Business Partner”
130;”N”;”Y”;”Y”;1;”Active Prospect/Customer”;”Business Partner”
140;”N”;”Y”;”Y”;26;”Potential Life Time Value”;”Business Partner”
150;”N”;”Y”;”Y”;26;”Acquisition Cost”;”Business Partner”
160;”N”;”Y”;”Y”;11;”Sales Volume in 1.000″;”Business Partner”
170;”N”;”Y”;”Y”;14;”First Sale”;”Business Partner”
180;”N”;”Y”;”Y”;1;”Customer”;”Business Partner”
190;”N”;”Y”;”Y”;1;”Vendor”;”Business Partner”
200;”N”;”Y”;”Y”;1;”Employee”;”Business Partner”

[Javier Ader]

tenes algún firewall? A mi me ha pasado con el firewall de XP que netstat y otro programas que muestran que puertos están abiertos que aunque permitía al programa abrir el puerto, filtraba todas las conexiones.
Otra cosa que podes hacer para testear los posibles errores es desde la linea de comandos:
telnet ITSB 1099
Este intenta crear un conexión TCP a la dirección ip o nombre que le pongas en el primer parámetro en el puerto especificado por el segundo. Si no puede establecer la conexión a nivel TCP te lo va a avisar.

[Javier Ader]

COPY tabla TO filename o STDOUT http://www.postgresql.org/docs/8.1/static/sql-copy.html
Tene en cuenta que postres tiene que tener permiso de escritura en la locación del archivo.
Un ej, que te puede servir si estas bajo Windows
copy libertya.ad_client to ‘E:/PostgreSQL/adclient’
(bajo linux en el link)
(fijate que hay usar / y no y que ahi uso el directorio de instalación de Postgres (la instalación lo creo con su propio usuario y este último solo tiene permiso en su propio directorio de instalación).
Lee un poco la documentación que trae bastante opciones, por ej le formato de salida, entre ellos CVS (y de nuevo tene cuidado bajo Windows que parece hacer bastante observaciones).

Si tenes que hacer exportaciones de solo ciertos filas de la tabla la verdad que no se…. tal vez la puedas hacer creando una tabla temporal.

[Javier Ader]

agrego algo que tal vez este influyendo. Ejecutando la última consulta (select name, isactive, isdisplayed, seqno from ad_field where AD_Field_ID in (1004135) en las base de 9.04 y en las de 10.03 note que cambio el numero de secuencia (90 en 10.3 y 100 en 9.04). Se habra generado un “choque” de secuencias de este campo con otro en la migración? No se que pasara si dos campos tienen asociada el mismo número de secuencia, pero debe traer sus problemas.
Se puede ejecutar esta consulta

Code:

select f.name, f.seqno, f.isactive, f.isdisplayed , t.name
from ad_field f inner join ad_tab t on (f.ad_tab_id = t.ad_tab_id)
where t.ad_tab_id = 220
order by f.isdisplayed desc

para ver todos los campos y sus números de secuencias asociados con el tab Bussiness Parner (en donde parece el Número de Ingresos Brutos); todos los que tienen isdisplayed = Y deberian tener distintos números de secuencia.
Si este es el problema seguro que se puede hacer una consulta sql que busque todos los tabs que tengan este tipo de problemas (supongo que también se solucionar diretamente desde sql pero lo veo más simple solucionar campo por campo desde libertya, ya que el orden final realmente no se sabe)

[Javier Ader]

creo que estas creando la pestaña bajo una numero de secuencia o “anidación” incorrectos. La pestaña tiene que filtrar por C_Invoice_Line_ID (esa es la que tenes que poner en “Columna Primaria” en la definición de la pestaña; bueno eso seguro que hiciste si no te tiraría el error). El tema es que al mostrar las entradas de la pestaña libertya ve que hay una columna primaria para la pestaña, y por lo tanto tiene que saber un valor X especifico X para C_Invoice_Line_Id (a nivel sql eso termina en algo como where C_Invoice_line_Id = x); ese X, si no recuerdo mal necesariamente tiene que venir de una pestaña “padre” que tenga este valor como un campo; en este caso la pestaña asociada a la linea de la factura. Bueno, esta pestaña tiene anidación 1, asi que tu pestaña tiene que tener anidación 2, pero el numero de secuencia determina cual de las pestañas de nivel 1 es la pestaña padre; en tu caso debe tener un valor mayor a Invoice Line, pero menor a Invoice Tax, ya que esta última también tiene nivel 1 (con 25 debería andar según mi base de datos; si no corre todas las pestañas a partir de Invoice Tax por 10, y ponele 30)

[Javier Ader]

bueno, ya que estoy digo otra obviedad jaja, pero en una de esas… existe la base de datos libertya en postgres? Si tenés pgadmin lo podes verificar; si no desde la linea de comando seguro que tambien, supongo que algo como
psql -U libertya -d libertya -h debian -c “select ad_client_id from libertya.ad_client”
o
psql -U postgres -d libertya -h debian -c “select ad_client_id from libertya.ad_client”

Muchas otras cosas no veo que puedan ser.
Si querés probar la conexión en si (e.d, si hay un error de permisos o no está escuchando el puerto defualt), podes ejecutar
psql -U posgres -d posgres -h debian
(también, proba -h 127.0.0.1 , -h 192.168.0.10 )

[Javier Ader]

bueno, salvo que no sea una simple errata lo que tenias que poner era 127.0.0.1, no 127.0.01. Igual, reiniciaste el servidor? (a postgres me refiero). Si no, no va a tomar efecto los cambios. Supongo que sabes como hacerlo, si no, jaja yo tampoco (hace rato que no uso ningún Linux…), pero reiniciando la maquina sirve (medio brusco pero bueno… si no, google; algun /etc/xxx.sh restart debe haber)

[Javier Ader]

bueno, ninguna de mis posibles soluciones andan. Creé una nueva base de datos y genere un preinstall.sql con CRLF separando al SELECT del AS; mismo error (“error de sintaxis cerca de SELECTAS”); asi que me parece que el unico separador que le gusta a postgres al menos bajo windows es es el espacio, quizá también tab (ok, no mire el código que le pasa estas sentencias a postgres, pero me da la sensación de que no va por ahi el tema).
Cambie el LF por espacio como antes y pase a probar tema del BOM. Modifique con notepad++ para que me agregue el BOM en el install.xml; instale y ahora me tiro el error en el install
====insertando metadatos de instalación===
Error al realizar la instalación: Content is not allowed in prolog.
mirando un poco en google (por ej http://forums.sun.com/thread.jspa?messageID=9436622#9436622) a las librerías de java tampoco les gusta el BOM…
En cualquier caso es raro que librerías hechas para manejar xml no se den cuenta que el archivo esta en UTF8 (aún mas teniendo el atributo encodig=”UTF-8″ en el tag xml).
Ahora me falta probar ejecutarlo con el flag -Dfile.encoding=UTF-8; ahi seguro que anda.

AGREGO: ahi lo probe con el flag e instalo correctamente el PSP01.zip que linkie más arriba… ahora me doy cuenta a que iba tu pregunta “Como lo ejecutaste?”. El tema de por qué con los juguetes anduvo, es porque muy probablemente lo haya corrido desde eclipse y eclipse setea el -Dfile.encoding=UTF-8, al menos en modo debug; no me habia imaginado está diferencia. Lo unico es que con o sin flag parece que el exportador si lo crea en UTF8 (el install.xml que use era el generado ejecutando el cliente “normal”).
Ahora, lo de LF o CRLF o lo que sea que pase con las vistas, creo que sigue estando.

[Javier Ader]

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)

Code:

CREATE TABLE M_Juguetes([LF]
[LF]
m_juguetes_id integer NOT NULL, etc etc etc

y el de la vista como

Code:

CREATE VIEW v_product_not_in_plv AS[LF]
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….)

[Javier Ader]

el tema creo que esta en que pg_hba.conf solo “confia” en direcciones de ip de la forma 127.0.0.XXX; vos cuando te conectas via el nombre “debian” lo más probale es que llegues a postgres usando la ip 127.0.1.1 y postgress la rechaza. Porque “debian” tiene la ip 127.0.1.1? es raro, ponele 127.0.0.1 en /etc/hosts o en vez de usar “debian” para entrar al sistema usa “localhost” o directamente 127.0.0.1 (no te diría que uses la ip asociada a la placa de red, SALVO que este seteada en modo estático y no via dhcp; en ese caso usando 192.168.0.10 también te debería andar, no solo desde tu propia maquina si no desde cualquiera en la red local)

PD : De Bahía, Mariano? Que chico es el mundo!

[Javier Ader]

en “nombre de base de datos” te falta poner libertya; otra opción es que postgress no este configurado para aceptar conexiones externas (pero no creo que sea este el problema)

[Javier Ader]

“Valoración de inventarios”, esa era concepto. Me da la sensación por lo que dice Antonio que esos asientos son generados aútomaticamente para dar un valoración de inventario en tiempo real, pero solo como dar un idea “del valor de los bienes”, así que en caso de ser un bug, no sería muy importante. Algo leí en google (es lo que hay jajaja) y me resulto raro que simplemente no se usase el precio de costo de los productos para esto. Meditando un poco me di cuenta que el tema debe venir cuando hay una disminución, por ej por una venta. Ahi no se sabe por cual valor disminuir (por ej, si tengo 10, 7 lapiceras que compre a un 1$, 3 a 2$, y vendo 8; por cuanto disminuyo mi valoración de inventario?). En este sentido, qué la valoración no ande tampoco cuando hay aumento de artículos no lo veo tan mal, ya que me da la sensación que en cualquier caso la valoración real es siempre un proceso “humano” (supongo que en un empresa, si el contador quiere decir que la valoración del inventario es X, tiene y va a ser X por más de lo que diga libertya o cualquier otro software de gestión).

Ahora, en cuanto a hacer una ventana para mostrar esta tabla o asociarsela como una pestaña a la venta de productos lo veo simple y se podría usar como una prueba de concepto para el framework de componentes.

[Javier Ader]

bueno, el tema de que haya múltiples precios complica un poco las cosas; asumo que vos que queres que se vean los 5 precios a la vez no? lo mismo para el stock? (e.d, 5 columnas para precios y 4 mas para cada los 2 stocks). Si es así, se puede armar una vista “muy a medida” (el tema es que si agregas un 6 precio, las cosas se complican ya que las vistas y en genral casi cualquier cosa no puede tener numero de columnas variable). Lo que si tambien se puede hacer es usar una tabla auxiliar para especificar que cuales son las listas de precios a mostrar. Lo mismo para los almacenes (aunque aca si veo muy poco probable que “agregues” un nuevo almacén; pero bueno, si pasa, es el mismo tema). El tema de todo esto es que no es muy flexible.
Lo de ocultar un precio, asumiendo la solución de vista, se puede hacer generando 2 vistas a nivel de postgress muy similares ( o que la segunda se base en la primera simplemente sacando una columna); y que les des permisos de manera especifica a cada perfil como lo haces con las ventanas normales (creo que libertya no permite crear dos tablas a nivel de metadatos asociadas a la misma tabla o vista postgress; una limitación que mucho no entiendo pero bueno…).
Lo que tiene de bueno todo esto, es que parece posible llevarlo a cabo incluso sin tocar una linea de código.

[Javier Ader]

Apa, esa también es muy buena. Lo que si es que la ventana de info siempre resulta “más linda”. Pero esta muy interesante tu planteo; simplemente habría que definir las columnas como de tal manera que permitan filtrar por estas (no me acuerdo bien cual era el atributo en la definición de columna que permitía esto; pero existia) y usar exactamente el mismo soporte que da el framework para las busquedas.
Ahora bien, las vista no debe ser para nada simple (fijate que por ej la venta info actual muestra cosas que estan en diversas tablas y tiene que hacer alguna forma de sumatoria para las cantidades en stock) pero supongo que se podría hacer.
Hermann que te parece esta idea? La ventana para mostrar los productos va a ser una ventana normal en donde el filtrado no va a ser directo (e.d, el usuario tiene que hacer click en el boton buscar y ahi especificar las cosas; y ese dialogo de busqueda normal creo que no “recuerda” cual fue las ultimas opciones de búsqueda, asi que el filtrado no puede ser “progresivo”; pero no estoy seguro de esto último)

[Autor]

Entradas