Proceso de migración de LibreOffice Base HSLQDB a LibreOffice Base Firebird

Unas notas sobre los problemas encontrados en el proceso de migración de 3 bases de datos.

Hay varias diferencias esenciales entre los dos SGDB.

El documento que describe las mismas es:

Migrating HSQLDB Base files to Firebird Base files, que se encuentra en: https://wiki.documentfoundation.org/Documentation/FirebirdMigration

Para comenzar hay que asegurarse que LibreOffice Base esté en modo HSLQDB.
Herramientas – Opciones – Avanzado – Activar funcionalidades expermientales (desactivado).

– Primero realizar una copia de la base que vamos a convertir, para trabajar con la copia, y dejar el original resguardado. Se le puede dar un nombre que no nos confunda, por ejemplo master_firebird.odb (dónde “master” es el nombre original de la misma.

– Editar todas las tablas, comprobando si tenemos campos “numéricos” o “decimales”. Caso de existir habría que cambiarlos por otro tipo de datos: “DOUBLE PRECISION”. Hay un bug, (que no ha sido aún corregido ni se sabe si va a implementar), que da errores en la conversión automática. La conversión, normalmente, no se puede hacer directamente por diferentes motivos.

– En caso de existir Vistas de Tablas habría que comprobar que la sintaxis se adapta a las nuevas características.
Ello se puede ver en el documento al que hice mención al principio.
La concatenación de campos solo puede hacerse un modo (‘str1’‖’str2’‖’str3’), extraer de una fecha el día de la semana, el año, el mes, el trimestre… no se realiza de la misma manera que hasta ahora. Y mas.

Si hay campos con datos decimales o numéricos, y están involucrados en Vistas de Tablas, no se pueden cambiar a DOUBLE con una instrucción SQL.

Las Vistas, una vez convertida la Base a Firebird no se pueden editar.

En mi caso me planteé cambiar las Vistas por consultas y evitar problemas.

La Vistas de Tablas, en Firebird, según mi opinión, existen por compatibilidad con versiones anteriores.

En Firebird se pueden crear vistas, en el modo de edicción de consultas, pero no se pueden modificar. No se puede acceder a la edición SQL, en la edición normal sale un editor, igual que el de tablas, en el que no se puede realizar ninguna operación.

Por ello he prescindido de las Vistas y he realizado unas consultas idénticas a las mismas, y con los mismos nombres.

He creado unas consultas, idénticas a las Vistas, He rectificado el resto de consultas. cambiando las que tuvieran origen en las Vistas, por su respectiva consulta. Si por ejemplo, tengo una Vista vMovimientos, he creado la consulta vMovimientos.

He creado unas consultas copiando la intrucción SQL de las vistas, les he puesto un nombre cualquiera. Una vez creadas todas, he eliminado las vistas y he cambiado el normbre de las consultas al que tenían anteriormente las vistas.

– Hay que tener precaución con el número de caracteres que tiene el nombre de una tabla, una consulta o una vista, al igual que el de los campos. El máximo número de dígitos que permite Firebird son 30 caracteres. En HSLQDB creo que eran 50. El error salta al ejecutar la consulta.

– Los nombres de la tablas y de los campos, incluidas las consultas, no deben incluir ciertos caracteres. quienes hablamaos español no podemos usar la “Ñ”. Me pasó con un campo que era Año. Tuve que cambiarlo por Anualidad.

– Una forma rápida de cambiar los campos númericos o decimales a DOUBLE es con una instrucción SQL (siempre que el campo no esté involucrado en una Vista de Tabla)

La instrucción es la siguiente: ALTER TABLE “NombreTabla” ALTER COLUMN “NombreCampo” DOUBLE

Dónde NombreTabla es el nombre de la tabla, NombreCampo es el de la columna y DOUBLE es el tipo de datos que quiero ponerle.

Firebird es mas estricto en la comprobación de las consultas que HSQLDB. Puede que alguna no funciones después de la conversión, arrojando error. Ya sería menos laborioso modificar las que den error.

Precaución y suerte.

Un saludo,
Emiliano.

Anuncios

Migración a LibreOffice Base Firebird.

Hace poco publiqué en el blog un artículo sobre la migración a LibreOffice 6.1 beta:
https://emilianoangel.wordpress.com/2018/06/05/migracion-a-libreoffice-6-1-base/

Tras hacer pruebas y demás tuve que dejar el cambio a la nueva versión de la base de datos, pues había algunos bug.

El problema mas importante que he encontrado ha sido por la conversión de campos numéricos y decimales de la versión de HSLQDB a Firebird.

Hay un bug que aún no ha sido resuelto.

Todo esto hacerlo con HSLQDB, antes de abrir la base a convertir con Firebird.

La solución es cambiar los campos “numéricos” o “decimales” a “DOUBLE PRECISION”.

Desde el editor de tablas, no se puede. Con instrucciones SQL, tampoco. Parece ser que en este tipo de campos no está permitida tal acción.

Solución, crear una nueva tabla, copiando la que se quiera modificar, pegar y en el proceso de pegado, cambiar los datos de los campos a DOUBLE PRECISION.

Siempre, en el pegado, aceptar la primera opción: “Definición y datos”.

Posteriormente hay que cambiar las posible vistas de tablas y las consultas, con los datos de la nueva tabla.

Una opción es en edición SQL, usando un editor de texto, con la opción de buscar y reemplazar.

Error que mostraba una consulta:

firebird_sdbc error:
*Dynamic SQL Error
*SQL error code = -104
*Invalid expression in the HAVING clause (neither an aggregate function nor a part of the GROUP BY clause)
caused by
‘isc_dsql_prepare’

Si la consulta se realiza tomando como criterio de agrupación el campo de una tabla, que sólo tiene una fila, muestra error. Es el ejemplo que sigue:

GROUP BY “Cuentas”.”cuenta” HAVING ( ( “Cuentas”.”cuenta” = “Parametros”.”cuenta” ) )

En cambio si pongo directamente el criterio no da errores.

GROUP BY “Cuentas”.”cuenta” HAVING ( ( “Cuentas”.”cuenta” = ‘DB Plus’ ) )

Para pedir los datos de los informes utilizo un formulario, que rellena la Tabla “Parametros”, sobrescribiendo los antiguos.

Solución. Relacionar “Cuentas.cuenta” con “Parametros.cuenta”. Solo en modo diseño de la consulta. En la columna problemática eliminar el criterio y activar, en Función: Agrupar por. En la SQL Sólo muestra el GROUP BY y desparece el HAVING. Por ahora vamos sorteando los obstaculos para usar Firebird.
Otro error era debido al nombre de una consulta. Tenía 40 caracteres. Se la ejecutaba directamente pues funcionaba como cualquier otra.
Pero si era origen de otra consulta ya mostraba un error. Decía que había un campo mas largo de la cuenta y no lo permitía.
Parece ser que HSQLDB permite hasta 50 caracteres como nombre de un campo o una tabla en la instrucción, pero Firebird lo máximo que permite son 30.
Se acortó el nombre, que era tan largo por un despiste, y arreglado el asunto.

Si hay formularios también habría que cambiar el origen de tablas de los mismos.

Si hay una columna tanto en tablas, como vistas o consultas con caracteres extraños, había de cambiarlas.

El problema se presentó con una que era “año”. La “Ñ” no la acepta, por ahora.

Si la base de datos no se compone de muchas tablas con datos problemáticos y muchas consultas que estén involucradas, pues es algo rápido, pero que hay que tener paciencia.

Enlaces interesantes:

https://wiki.documentfoundation.org/Documentation/FirebirdMigration

https://wiki.documentfoundation.org/Development/Base/FirebirdSQL

https://wiki.documentfoundation.org/Faq/Base

https://wastack.wordpress.com/

Migración a LibreOffice 6.1 Base

Hace unos días se ha publicado la beta1 de LibreOffice 6.1.
He descargado el paquete y lo he instalado en Fedora 28.
Al ser una versión de desarrollo, al ejecutarse, crea sus propios directorios de usuario, distintos de los de la versión estable.

El motor de base de datos que viene implementado por defecto es Firebird, aunque HSQLDB sigue funcionando normalmente.

Al abrir una base de datos realizada con HSQLDB, que puede ser cualquier base realizada con una versión menor (salvo que se hubiera activado Firebird anteriormente) siempre solicita convertirla a Firebird.

Esto se puede obviar presionando el botón “latest” en vez de “yes”.

Para convertirla a la versión de Firebird hay que tener presente varias cuestiones, pues el sistema de conversión aún tiene fallos:

Realizar un copia de seguridad de la base de datos que queremos abrir y trabajar con la copia.

Comprobar si tenemos alguna vista de tabla. Es decir en el menú “tablas” están las tablas propiamente dichas y la vistas, que no son mas que una consulta, que puede ser de tablas combinadas.

En caso de que existan vistas de tablas hay que abrirlas y comprobar que no haya campos calculados o campos concatenados que no estén realizados de manera que puedan ser correctamente interpretados por la nueva versión, pues en caso contrario la vista se elimina en la conversión.

Si hay campos calculados o campos concatenados en la vista lo mejor es crear una nueva consulta en modo SQL, copiar la instrucción SQL que nos muestra la vista y guardar la nueva consulta que hemos realizado con esta instrucción SQL copiada.

El error mostrado venía dado por un campo concatenado, que no se ajustaba a Firebird. En la consulta cambié la instrucción y conseguí que funcionara.
Usaba: “Prenom” + SPACE( 1 ) + “Nom”
Rectifiqué: “Prenom” || ‘ ‘ || .”Nom”

A continuación tendríamos que comprobar todos las consulta que tenemos. En la que figure la vista de tabla habría que cambiar todos los datos por los de la consulta.

Un método puede ser con un editor de texto y la edición SQL de consultas.

En mi caso la vista de tabla de llamaba vMovimientos y la consuta creada con la misma instrucción c_vMovimientos. Copiaba el resultado de la salida de la consulta en un editor de texto (kate) y con buscar y remplazar ya tenía la nueva sintaxis. Volvía a copiar y pegar. Guardaba la consulta y la base. Resuelto parcialmente.


La consultas con parámetros, si en criterio se hace referencia a un campo de una tabla, poniendo <= [tabla].[campo] muestra error.

Los campos numéricos y con decimales dan problemas.
Tengo en una tabla “Movimientos” que tiene, entre otros, tres campos “DECIMAL” con dos decimales.
Al importar los campos INTEGER, DATE, VARCHAR Y BOOLEAN no han dado problemas, pero los DECIMAL sí.

Había cantidades que no daban problemas, pero en otras el resultado era desastroso.
Números positivos los convertía en negativos que no tenía relación alguna, las cantidades con decimales terminados en 00 las dividía por 100. 9000,00 pasaba a ser 90,00, un 9xx,xx lo pasaba a -16xx,xx.

Para solucionarlo copio desde la base guardada y, abierta con una versión antigua, la tabla en Calc:
Crear tres nuevas columnas,
Multiplicar el resultado por 100.
Cambiar a formato numérico y sin decimales.
Transponer a sus antiguas columnas.

Con esto ya puedo realizar la exportación de datos a la tabla Movimientos de la nueva base convertida.

Parece un proceso muy engorroso, pero si se hace con tranquilidad, en poco tiempo se ha finalizado.

Por ahora, en la comprobación que he realizado, tanto los datos de fecha como los numéricos están correctos, sin que haya diferencia entre una y otra tabla.

NOTA.- En una comprobración posterior, y en un campo calculado, el resultado del mismo es el que he importado de la hoja de cálculo, no de lo que figura en la tabla.

Es decir, está multiplicado por 100 con respecto a lo que figura en la tabla.

El bug ha sido reportado por Xisco Fauli @x1sc0    https://bugs.documentfoundation.org/show_bug.cgi?id=118043 .

 

BITDEFENDER ANTIVIRUS SCANNER EN FEDORA 27

BitDefender Antivirus Scanner for Unices, un antivirus de BitDefender y que se puede utilizar gratuitamente.

La página de descarga es:

https://www.bitdefender.es/business/antivirus-for-unices.html

Después deberemos solicitar una licencia gratuita por un año, esta parte si que está visible desde el enlace Solicite licencia gratuita, que nos mandará una clave a nuestro email.

Una vez descargado, simplemente ejecutamos (sin olvidarnos de hacerlo ejecutable), como root:

sh BitDefender-Antivirus-Scanner-7.7-1-linux-amd64.rpm.run

Seguimos las instrucciones de la terminal, incluyendo escribir la palabra accept e indicando que queremos instalar también la interfaz gráfica.

El software ha sido discontinuado desde principios de 2016. Esta versión 7.7.1, data de noviembre de 2014, que en software antivirus es un mundo, las firmas siguen actualizándose diariamente, esencialmente son las mismas que usan otros productos de BitDefender, así que ningún problema.

Como habéis podido ver, además tiene versión nativa de 64 bits, que es de las cosas que más me gustan en BitDefender.

Si te has registrado con anterioridad y tienes licencia, puedes descargarlo directamente de:
https://download.bitdefender.com/SMB/Workstation_Security_and_Management/BitDefender_Antivirus_Scanner_for_Unices/Unix/Current/EN_FR_BR_RO/Linux/

Para evitar errores y que se carguen los motores antivirus, una vez instalado hay que ejecutar estos dos comandos, como root:

ln –force –symbolic /opt/BitDefender-scanner/var/lib/scan/Plugins /opt/BitDefender-scanner/var/lib/scan/Plugins/plugins
(todo lo anterior en la misma linea, pues es un único comando)

ll /opt/BitDefender-scanner/var/lib/scan/Plugins/plugins

Con ello ya se puede arrancar el programa, proceder al cambio de licencia (la consta es la de evaluación), actualizar las firmas y comenzar el escaneo.

Error al inicio de Linux debido a CUPS

Uso Fedora 25 KDE. Desde hace tiempo y, con varias versiones anteriores. se está produciendo el mismo fallo al inicio del sistema.

Para ver los errores que se han producido en el inicio de sesión, en los sistemas que incorporan Systemd, hay que teclear el comando:

[root@HOST-PC ~]# journalctl -b -p err

Uno de los que estaba arrojando últimamente era:
cupsd[1213]: Missing value on line 11 of /var/cache/cups/job.cache.

Los números 1213 y 11 pueden variar. El primero debe ser un índice de Journal (el registro de logs de Systemd) y el segundo hace referencia a la línea del fichero job.cache que produce el fallo.

Es este caso era debido a que cups-pdf (la impresora virtual) al crear un fichero no le asignó un nombre en el archivo job.cache.

Intenté borrar la caché de Cups desde el administrador de impresión (system-config-printer), pero no se encontraban trabajos pendientes ni terminados. También desde la interfaz web del servidor cups: http://localhost:631/jobs?which_jobs=all

No era posible. No se podía borrar. Incluso eliminé el contenido de  job.cachecon un editor de texto, pero al volver a iniciarse el contenido estaba otra presente, así como el error se reproducía.

Al final la solución llegó a través de la consola.

Los comandos a ejecutar son:

Parar Cups:

[root@HOST-PC ~]# systemctl stop cups.service

Ver la lista de trabajos completados:

[root@HOST-PC ~]# lpstat -W completed -o

Ver la lista de trabajos no completados:

[root@HOST-PC ~]# lpstat -o

Eliminar todos los trabajos:

[root@HOST-PC ~]# cancel -a -x

Esto cancelará todos los trabajos.

Editar el fichero  /var/cache/cups/job.cache, borrar el contenido y guardar de nuevo.

por ejemplo con nano como root

[root@HOST-PC ~]# nano /var/cache/cups/job.cache

Reiniciar el sistema y ver si se ha solucionado el fallo.

SI las respuestas dadas aquí no funcionan:

ps aux | grep printer kill {printer job}

Este último comando no lo he probado. con lo anterior fue suficiente.

Un saludo,

Emiliano

 

Instalar dos versiones de LibreOffice en Fedora 23

Debido a un bug en LibreOffice Base 5.0, que resulta bastante molesto, he tenido que instalar dos versiones del mismo.

Uso Fedora 23 kde de 64 bits. En los repositorios sólo está LibreOffice 5.0. La versión 4 es para Fedora 22

Uno de los programas que me interesa es Base. El motivo es la gestión de dos BB.DD. de escritorio.

Las tengo preparadas desde hace tiempo en Access de MS-Oficie 2003, pero tengo ganas de desprenderme de Virtual-Box y la MV de Windows 7. Sólo lo utilizaba para estabas bases de datos.

Con LibreOffice 4 no tenía problemas con las BB.DD., pero con la versión 5.0 comenzaron a aparecer.

El primero, que no aceptaba los cambios en el tipo de fuentes ni en el resto de formatos en tablas, consultas y control de tablas de formularios. Tomaba la fuente del sistema, creo, y no había forma de cambiarla. Tenías que irte a Preferencias del sistema y en fuentes, variabas el tamaño, y veías si te gustaba el formulario a imprimir, si cabían todos los caracteres en sus casillas, etc. Vamos un lio.

El segundo, ya en la última versión (5.0.4.2) es con los controles tabla de los formularios. No se pueden editar. Imprimes y te salen unas letras gigantes en los encabezados de las columnas.

He probado en varios ordenadores, distintas distribuciones, e incluso en Windows 7 y 10.

El patrón siempre es el mismo, con LibreOffice 5.0 el bug se repite, con la versión 4 no.

Ambos errores están reportados en varias ocasiones, sin resultado hasta la fecha.

Total que quise probar instalando dos versiones: LibreOffice, instalación en paralelo.

Pero no había forma, lanzaba el comando y siempre daba error.

Total que con DNF desinstalé LibreOffice Base 5.0, descargué de la página de LibreOffice la versión 4.7, descomprimí todos los archivos en un directorio y, desde la línea de comandos, instalé lo mínimo indispensable: base, Writer y los paquetes de idiomas. Si me solicitaba algún paquete mas lo añadía al comando. (Writer es necesario para poder visualizar los formularios y los informes).

Otro cambio que hubo que realizar fue el de los iconos. Sustituir Breeze por Oxygen.

Lo “malo” es que la integración de escritorio de base no es la misma que la del resto de paquete. Fedora siempre ha mantenido la interfaz de LibreOffice igual que el resto del escritorio, sin desentonar. Con el instalador descargado de la página de LibreOffice, aunque instales el paquete de kde, nunca queda bien, los colores desentonan, el navegador de archivos es antiguo y no sigue el patrón de Dolphin, etc.

Otro problema que hay es que si tienes abierto base no se puede abrir Writer o Calc 5.0.

Pero hasta que se solucione el bug no habrá más remedio que hacerlo así. No tengo ganas de hacer una instalación de Fedora 22 en Virtual-Box para poder tener la versión 4.7

Parece que base es “el patito feo” de LibreOffice. Por lo que se ve en las notas de lanzamiento de las distintas versiones y lo que se dice en foros, blogs, redes sociales, etc. es que las novedades son mínimas y hay bug que se arrastran y tardan en arreglarse.

Un saludo,

Emiliano

Instalar BlueGriffon 1.7.2 en Fedora 20

Volvemos con la instalación de Bluegriffon.

No sé si está discontinuado, pero lleva sin actualizar desde el 19/07/2013 que salió la versión 1.7.2

El problema para la instalación es que necesita xulrunner 26 y la versión de los repositorios, a día de hoy, es la 30.

He encontrado el fichero en rpm y no es es necesario instalar el tar.bz2.

Los archivos para instalar son:

32 bits:

https://kojipkgs.fedoraproject.org//packages/xulrunner/26.0/2.fc20/i686/xulrunner-26.0-2.fc20.i686.rpm

http://fr2.rpmfind.net/linux/local/fedora/20/i386/os/Packages/bluegriffon-1.7.2-5.fc20.i686.rpm

64 bits

https://kojipkgs.fedoraproject.org//packages/xulrunner/26.0/2.fc20/x86_64/xulrunner-26.0-2.fc20.x86_64.rpm

http://fr2.rpmfind.net/linux/local/fedora/20/x86_64/os/Packages/bluegriffon-1.7.2-5.fc20.x86_64.rpm

Una vez instalado hay que evitar que xulrunner se pueda actualizar a una versión más reciente.

Para ello hay dos opciones, ambas a ejecutar desde la consola, y como usuario root.

Editar el fichero /etc/yum.conf y añadir la siguiente linea:

exclude=xulrunner

Pegar en consola y darle a intro: echo ‘exclude=xulrunner’ >> /etc/yum.conf

La más sencilla la segunda.