- Este debate está vacío.
-
Entradas
-
Fui haciendo paso a paso la instalación y al tratar de migrar la base de datos falló, con el siguiente mensaje (ver imagen) :
La base de datos està standard, parametrizada. Es una copia de la que debo actualizar de un cliente.
Agradezco las intervenciones/ayudas anticipadamente.
Buenas,
Algunas consultas para ir determinando el origen del problema:
Qué versión de PostgreSQL estás corriendo?
Algún indicio sobre qué consulta en especial es la que está trayéndote problemas en el archivo /ServidorOXP/Component_install_XXX.log?
Dado que comentás que la instancia se encuentra parametrizada, has realizado alguna modificación en especial en relación con las tablas de factura electrónica?
Saludos,
FedericoPerdón por no poner antes más datos.
Tengo Ubuntu 10.04 con PostgreSql 8.3.11-0Lenny, proveniente del repositorio de Debian (ya que la versión 10.04 de Ubuntu viene con PostgreSql 8.4). Esto, por supuesto, con las dependencias necesarias para que funcione (también de Debian).
Todo esto ejecutándose en una máquina virtual virtualbox.En el motor tengo 4 bases de datos.
Esta en particular se llama Libertya y está parametrizada toda, menos la factura.
Como toques particulares tiene un plan de cuentas ampliados y nada más.Casualmente quiero probar la ampliación de colores y talles.
Cosas que noté :
– No indicó que la base de datos estaba desactualizada.– El cliente “Libertya.sh” indicó versión 10.03 (a pesar de poner que reemplazara todo el /ServidorOXP al descomprimir – con sudo).
– No creó el log del instalador de componentes, pero largué la aplicación desde consola y pude capturar los siguientes mensajes :
Code:carlos@ubuntuserver:/ServidorOXP$ ./Libertya.sh
Cliente Libertya v10.03
JAVA_HOME no esta establecido
Debe establecer la variable JAVA_HOME
Establecer JAVA_HOME al directorio base del JDK de java.
La variable OXP_HOME no aparece establecida
Deebe establecer la variable OXP_HOME
al directorio base del servidor de Libertya.
*** 2010-10-26 15:48:13.539 OpenXpertya Log (CLogConsole) ***
15:48:12.837 OpenXpertya.startup: Libertya (r) Versión 10.03_15-03-2010 – Software Libre de Gestión- (c) 2009 DISYTEL; Implementación: Libertya 20100315-1136 – SERVICIOS_DIGITALES [11]
15:48:12.837 OpenXpertya.startup: – OpenJDK Client VM 16.0-b13 – Linux 2.6.32-25-generic-pae unknown [11]
———–> CConnection.setAppsServerInfo: jnp://Servidor_Aplicaciones:1099
– javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]
– {java.naming.provider.url=jnp://Servidor_Aplicaciones:1099, java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory, jnp.discoveryTimeout=5000, jnp.timeout=5000, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces, jnp.sotimeout=5000} [11]
———–> CConnection.setAppsServerInfo: jnp://Servidor_Aplicaciones:1099
– javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]
– {java.naming.provider.url=jnp://Servidor_Aplicaciones:1099, java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory, jnp.discoveryTimeout=5000, jnp.timeout=5000, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces, jnp.sotimeout=5000} [12]
===========> MSession.saveNew: saveNew [11]
org.postgresql.util.PSQLException: ERROR: llave duplicada viola restricción de unicidad «ad_session_key»; State=23505; ErrorCode=0
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1512)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1297)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:437)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:353)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:307)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.postgresql.ds.common.PooledConnectionImpl$StatementHandler.invoke(PooledConnectionImpl.java:467)
at $Proxy1.executeUpdate(Unknown Source)
at org.openXpertya.util.CPreparedStatement.executeUpdate(CPreparedStatement.java:227)
at org.openXpertya.model.PO.saveNew(PO.java:2557)
at org.openXpertya.model.PO.save(PO.java:1783)
at org.openXpertya.model.MSession.get(MSession.java:246)
at org.openXpertya.apps.AMenu.(AMenu.java:106)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)===========> MSession.saveError: Error – Error por clave duplicada [11]
===========> MSession.saveNew: Not inserted – INSERT INTO AD_Session (AD_Client_ID,AD_Org_ID,AD_Session_ID,Created,CreatedBy,IsActive,Processed,Remote_Addr,Remote_Host,Updated,UpdatedBy) VALUES (?,?,?,?,?,?,?,?,?,?,?) [11]
=== Instalando Componente y Version. Registrando Plugin ===
=== Ejecutando sentencias de preinstalacion ===
Error al realizar la instalación: ERROR: no hay restricción unique que coincida con las columnas dadas en la tabla referida «ad_electronicinvoiceformat»
———–> Msg.getMsg: NOT found: Error al realizar la instalación: ERROR: no hay restricción unique que coincida con las columnas dadas en la tabla referida «ad_electronicinvoiceformat» [12]
———–> Msg.getMsg: NOT found: OXPSYS [12]
———–> Msg.getMsg: NOT found: OXPSYS [12]Quote:Cosas que noté :
– No indicó que la base de datos estaba desactualizada.– El cliente “Libertya.sh” indicó versión 10.03 (a pesar de poner que reemplazara todo el /ServidorOXP al descomprimir – con sudo).
– No creó el log del instalador de componentes, pero largué la aplicación desde consola y pude capturar los siguientes mensajes :
Por lo que aquí indicás, los binarios no se han actualizado correctamente. (pareciera que seguís con la versión 10.03).
Más allá del problema que indicaste inicialmente, primeramente deberías ver de resolver este tema. Como alternativa, y para descartar posibles errores, en lugar de pisar el directorio, renombrá el ServidorOXP a ServidorOXP_old, y descomprimí la versión 10.09 en ServidorOXP, reconfigurá y probá ahora sí a actualizar la base de datos.
Saludos,
FedericoComo aporte y porque tengo años de linux, muchas veces falla la descomprecion con sudo por cuestiones a veces de permisos.
Chequea que tengas los permisos para eso, o ingresa como root y despues descomprimes y copias.saludos
efectivamente no se habían actualizado como correspondían los binarios.
Luego de hacerlo correctamente los primeros mensajes aparecieron como debía, sin embargo no pude migrar la base de datos.
Luego de varias vueltas, abrí el jar y fui tomando instrucción por instrucción y el problema que encontré fue que debía agregarle el nombre de la base de datos que quería alterar a cada instrucción ALTER.
En el motor en cuestión, tengo 4 bases de datos.
En el servidor tengo bajo el application server.
Existe alguna intrucción para setear la base de datos (fuera de cuando se hace la conexión), para agregar al principio del preinstal.sql?
Por otro lado no se genera el log de la actualización.Buenas,
Me extaña que ese sea el problema, ya que la conexión a una base de datos específica la gestiona LY una vez conectados a la aplicación. ¿No te estarás refiriendo a que debés indicarle el schema, el cual casualmente se llama libertya? De ser así, cabe preguntar qué usuario DE BASE DE DATOS estás usando para conectar a LY desde el cliente.
Si el usuario es libertya, el schema por defecto de dicho usuario es libertya, y es por ésto que no es necesario indicar el prefijo “libertya.tablaXXX” en las sentencias sql, si no estás usando el schema libertya, entonces quizás por ahí venga el problema.
En resumen, intentá conectarte al sistema utilizando una conexión a base de datos mediante el usuario libertya.
Respecto al log, muy probablemente no se esté generando por un tema de permisos sobre el directorio /ServidorOXP.
Saludos,
FedericoFede, revisé la seguridad del Ubuntu. Ahora permito TODO a TODOS y logré generar un log.
En el motor tengo 4 bases de datos. Cada una de ellas tiene el esquema Libertya.
Lancé la actualización con el script install.sql modificado para que apuntara adonde necesitaba, pero, error mío, como los esquemas son en realidad libertya, falló (los esquemas de las 4 bases de datos son libertya y yo utilicé el nombre de la base de datos).
Todo bien, porque generó el log.
Cargué el install.sql original en el jar y ejecuté todo de nuevo.
Volvimos a no generar log ni hacer ninguna tarea.
Por las dudas. Reinicié todo el servidor.
Sigue sin generar el log ni ejecutar nada.
La verdad no sé dónde mirar, son sentencias sql que no se ejecutan.
El problema que tengo que justo la grilla de talle color es lo que me está haciendo falta.
Qué pasaría si al install.sql le dejo una línea o lo dejo vacío y ejecuto vía pgAdmin todas las sentencias sql?Quote:Lancé la actualización con el script install.sql modificado para que apuntara adonde necesitaba, pero, error mío, como los esquemas son en realidad libertya, falló (los esquemas de las 4 bases de datos son libertya y yo utilicé el nombre de la base de datos).En realidad, como te decía previamente, si estás utilizando el usuario libertya para conectarte a la base de datos desde el cliente LY, y el esquema es libertya, no deberías modificar el preinstall.sql en absoluto. Simplemente accedé a la aplicación como System Administrator. El instalador de componentes realizará la actualización sobre la base de datos a la cual te conectaste. Simplemente con seguir la guía con los pasos de actualización debería salir andando.
Quote:Volvimos a no generar log ni hacer ninguna tarea.No creo que la generación del log dependa del sql que estés ejecutando. Te aconsejaría realizar la instalación mediante el usuario root para descartar cualquier tema con los permisos. Más allá de que no se genera el archivo de log, qué información se te presenta en la ventana del instalador de componentes?
Quote:Qué pasaría si al install.sql le dejo una línea o lo dejo vacío y ejecuto vía pgAdmin todas las sentencias sql?La aplicación utiliza una transacción para el proceso de instalación, que de encontrar un error realiza el rollback correspondiente para dejar la base de datos en el estado previo a la instalación. Lo que pasaría es que la instalación no correría por una transacción. Si luego tenés un problema en el install.xml o el postinstall.xml, vas a tener una base de datos inconsistente y relativamente inservible.
Saludos,
FedericoNo hay caso, no migra.
Arranqué con sudo el cliente libertya (en ubuntu equivale a root).
No generó log y no actualizó nada.
Borré 3 de las 4 bases de datos, dejé la que instala por defecto y no migra.
Hay algún proceso que no se está ejectuando.
Estoy trabajando con máquinas virtuales, así que mi backup es un clon del disco virtual.
Reemplacé los fuentes (en ese momento tuve problemas y los corregí), luego modifiqué la seguridad (hoy todos pueden reemplazar), ingreso como system (le digo que no actulice la base de datos), selecciono opción instalador de componentes y plugins (dentro de configuración/configuración de componentes), selecciono el plugin org.libertya.core.upgrade_10.03-10.09.jar, me muestra los datos del componentes, le doy instalar, indico que “sí” a la advertencia de que voy a instalar, presenta los mensajes “Instalando componente y version. Registrando plugin” y “Ejecutando sentencias de preinstalación”, y ahí queda.
Me pueden dar una mano. En dónde miro/busco?
Estoy con 384 kb de memoria, pero no veo que la use toda. El uso del procesador sube, pero al cabo de unos segundos baja.
Las instrucciones a mano funcionan. Para mí que no llega al punto de ejecutarse, como si fallara antes de ejecutar el sql.Perdón, no lei nada… pero bueno; doy algunas ideas:
-que se “cuelgue” (no responda ni un error), no será porque un tema de concurrencia? El preinstall se ejecuta dentro de una trasnaccion; si por alguna razón hay otra transacción desde otro lado accediendo a la misma base de datos (digamos el procesador contable) se pueden bloquerar … medio raro igual.
-“Las instrucciones a mano funcionan”: las instrucciones del preinstall.sql las ejecutaste antes a mano? Bueno, no te va andar la instalación si las ejecutas sobre la misma base de datos (estarías ejecutando el preinstall dos veces); no creo que lo hayas hecho así, pero por las dudas.
También, si el preinstall.sql anda a mano, lo que podes hacer es: las ejecutas a mano (pero logueandote como el usuario correcto de postgres, el mismo que usa libertya (por defecto “libertya”); si no te van a quedar mal los permisos de las tablas); descomprimís el jar con cualquier compresor zip; le sacas el preinstall.sql (dejale uno preinstall.sql vacio por las dudas); volves a comprimir todo como un zip; le cambias la extensión a .jar y probas con este nuevo.
Ahí obviamente el preinstall los vas pasar….
Si te pasa lo mismo en la etapa postistall haces lo mismo, pero usando postinstall.sql.
(igual esto seria un hack… el problema real debe venir por otro lado…)PD : el tema del UTF8 en los archivos no será?
PD 2: mientras se esta haciendo la instalación de un plugin, podes mirar el log desde libertya mismo (creo…); antes de iniciar la instalación anda a preferencias y pone el nivel de log a alguno bajo (ALL creo que se llama el mas abarcador); cuando ves que la instalación se cuelga, deberías poder ir Preferencias y ver el log. De esta manera, no importa si después se cuelga la ventana de instalación; el log lo vas a tener (y supongo que pasandole las ultimas entradas a Federico va a poder mejor por donde va la cosa)Gracias por tus aportes.
El problema no debe ser concurrencia porque es lo único que estoy haciendo. El servidor de aplicaciones está bajo, es un máquina virtual de prueba (no producción) y estoy ejecutando el cliente desde la misma máquina (local).
El problema es en postgresql. Si cuando “se clava” que no responde ni me deja ver las preferencias, trato de ver la base de datos desde pgAdmin, el mismo queda sin respuesta.
Las instrucciones que probé a mano fueron crear los índices únicos y relacionados (probé 3 o 4 instrucciones) y luego las volví atrás.
UTF8? La instalación está por defecto, no creo, pero; cómo podría controlar esto?
Voy a revisar a ver que dice en el instalador de esto.
Voy a revisar el documento de ajustes básicos de postgresql.
Si todo esto está bien, voy a probar ejecutando a manos las instrucciones (antes de instalar, ya que es pre) y voy a ver las de post (en el install están todos los updates de versión).
Insisto, estoy prácticamente convencido que es el postgresql, porque también se clava el pgAdmin3.
Si alguien se le ocurre algo en este punto será bien recibido.
Gracias de antemano.Agregado extra.
Si bien no generó el log del component, sí puedo ver el log de postgresql.
Se ejecuta hasta la línea 250, donde crea la tabla ad_replicationhost.
Luego de esto viene Ampliación de esquemas de descuentos y etc.
Es como si se quedara corto de algo, como si la transacción fuera muy grande.
Puede ser?
Alguien puede aportar algo?
GraciasQuote:Arranqué con sudo el cliente libertya (en ubuntu equivale a root).Si no te genera el log, te recomendaría cambiar a usuario root durante el período de instalación. En varias ocasiones el comando sudo no funciona como se espera (más que nada cuando se realizan tantas actividades distintas)
Quote:No generó log y no actualizó nada.Recién cuando aceptes el Dialogo de actualización en la ventana de instalador de componentes empezará a generar el log (nuevamente, si están los permisos de escritura]).
Quote:Presenta los mensajes “Instalando componente y version. Registrando plugin” y “Ejecutando sentencias de preinstalación”, y ahí queda.Ahí queda… por cuanto tiempo? Tené en cuenta que puede demorar varios minutos este paso. Obviamente si al cabo de un tiempo no hay novedades, algo raro está pasando.
Quote:Si te pasa lo mismo en la etapa postistall haces lo mismo, pero usando postinstall.sql.Este archivo NO existe. El install.xml y postinstall.xml son generados a partir de bitácora y en funcion del parseo de los mismos se generarn las sentencias SQL. Es imposible realizar lo mismo sobre estos archivos como podría hacerse con el preinstall.sql.
Quote:PD : el tema del UTF8 en los archivos no será?No me parece que venga por acá. Además los archivos de inicio de cliente libertya ya tienen especificado utilizar UTF8.
Quote:Insisto, estoy prácticamente convencido que es el postgresql, porque también se clava el pgAdmin3.Qué PostgreSQL estás usando? Quizás venga por ahí el tema. Las pruebas las hemos realizado mayormente sobre la versión 8.2. Estás usando la 8.3?. Podrías pasarnos el log para verlo?
Saludos,
FedericoFede, estoy utilizando Postgresql 8.3
Lancè la actualizaciòn, y despuès de dejarlo toda la noche, lo cancelè y en el log del motor podemos ver las siguientes lìneas :2010-11-19 15:32:12 ART NOTICE: ALTER TABLE / ADD PRIMARY KEY creará el índice implícito «ad_electronicinvoiceformat_key» para la tabla «ad_electronicinvoiceformat»
2010-11-19 15:32:12 ART NOTICE: ALTER TABLE / ADD PRIMARY KEY creará el índice implícito «ad_electronicinvoiceformathdr_key» para la tabla «ad_electronicinvoiceformathdr»
2010-11-19 15:32:12 ART NOTICE: ALTER TABLE / ADD PRIMARY KEY creará el índice implícito «ad_electronicinvoiceformatline_key» para la tabla «ad_electronicinvoiceformatline»
2010-11-19 15:32:12 ART NOTICE: ALTER TABLE / ADD PRIMARY KEY creará el índice implícito «e_electronicinvoice_key» para la tabla «e_electronicinvoice»
2010-11-19 15:32:12 ART NOTICE: ALTER TABLE / ADD PRIMARY KEY creará el índice implícito «e_electronicinvoiceline_key» para la tabla «e_electronicinvoiceline»
2010-11-19 15:32:12 ART NOTICE: ALTER TABLE / ADD PRIMARY KEY creará el índice implícito «e_electronicinvoiceref_key» para la tabla «e_electronicinvoiceref»
2010-11-19 15:32:12 ART NOTICE: ALTER TABLE / ADD PRIMARY KEY creará el índice implícito «t_electronicinvoice_key» para la tabla «t_electronicinvoice»
2010-11-19 15:32:12 ART NOTICE: CREATE TABLE / PRIMARY KEY creará el índice implícito «m_product_upc_key» para la tabla «m_productupc»
2010-11-19 15:32:12 ART NOTICE: CREATE TABLE / UNIQUE creará el índice implícito «unique_upc_by_client» para la tabla «m_productupc»
2010-11-19 15:32:13 ART NOTICE: ALTER TABLE / ADD PRIMARY KEY creará el índice implícito «ad_scheduler_para_key» para la tabla «ad_scheduler_para»
2010-11-19 15:32:13 ART NOTICE: CREATE TABLE / PRIMARY KEY creará el índice implícito «c_pospaymentmedium_key» para la tabla «c_pospaymentmedium»
2010-11-19 15:32:13 ART NOTICE: CREATE TABLE / PRIMARY KEY creará el índice implícito «m_entidadfinancieraplan_key» para la tabla «m_entidadfinancieraplan»
2010-11-19 15:32:14 ART NOTICE: CREATE TABLE / PRIMARY KEY creará el índice implícito «ad_changelog_replication_key» para la tabla «ad_changelog_replication»
2010-11-19 15:32:14 ART NOTICE: CREATE TABLE / PRIMARY KEY creará el índice implícito «ad_tablereplication_key» para la tabla «ad_tablereplication»
2010-11-19 15:32:14 ART NOTICE: CREATE TABLE / PRIMARY KEY creará el índice implícito «ad_replicationhost_key» para la tabla «ad_replicationhost»
2010-11-19 15:32:14 ART NOTICE: CREATE TABLE / UNIQUE creará el índice implícito «ad_replicationarrayuk» para la tabla «ad_replicationhost»
2010-11-20 11:00:42 ART LOG: se encontró fin de archivo inesperado en la conexión del cliente
2010-11-20 11:00:42 ART LOG: se encontró fin de archivo inesperado en la conexión del cliente
2010-11-20 11:00:42 ART LOG: se encontró fin de archivo inesperado en la conexión del cliente
2010-11-20 11:00:42 ART LOG: no se pudo enviar datos al cliente: Conexión reiniciada por el par
2010-11-20 11:00:42 ART LOG: se encontró fin de archivo inesperado en la conexión del cliente
2010-11-20 11:00:44 ART LOG: no se pudo enviar datos al cliente: Tubería rota
2010-11-20 11:00:44 ART SENTENCIA:
UPDATE ad_process_access SET AD_ComponentObjectUID = ‘CORE-AD_Process_Access-1000060-1000115’, ad_componentversion_id = (select ad_componentversion_id from ad_componentversion where ad_componentobjectuid = ‘CORE-AD_ComponentVersion-1010012’) WHERE ad_process_id = 1000115 AND ad_role_id = 1000060
2010-11-20 11:00:44 ART LOG: mensaje incompleto del clienteNo da ningùn mensaje de error en la consola de actualizaciòn ni graba el log.
Voy a habilitar el usuario root (ubuntu no lo tiene habilitado por defecto) y voy a tratar de actualizar con èl (no creo que vaya a funcionar, pero veremos).
Luego de esto probarè a mano (preinstall.sql) y luego actualizarè, dejando ese archivo vacìo para que no se trabe.Llegamos al fondo, creo.
Ejecuté todas las instrucciones del preinstall.sql (a excepción de aquella que cambia la versión “– Fecha de release
UPDATE ad_system SET version = ’24-09-2010′ WHERE ad_system_id = 0;”. Esta es la única instrucción que dejé en el archivo preinstall.sql, dentro del jar de actualización.
Ejecuté los pasos habituales (me logueé como system, fui a instalar componentes y elegi el componente de actualización.
Esta vez sí generó el log (nunca había llegado hasta aquí), pero falló la actualización, y la verdad es que el log no dice nada.
LOG
=== Instalando Componente y Version. Registrando Plugin ===
=== Ejecutando sentencias de preinstalacion ===
=== Comprobando secuencias de nuevos componentes – preinstalacion ===
Error al realizar la instalación: null
Alguien hizo un upgrade correctamente?
Voy a armar una instalación en Windows y tratar de actualizar las base de datos desde la misma.
- Debes estar registrado para responder a este debate.
