Back-end sencillo

[JoseJuan]

Hola a todos.

Por más que busco, no encuentro la forma de separar los datos del resto de la aplicación en Base. También he hecho muchas pruebas y ninguna me ha funcionado.
La idea es montar un front-end con la aplicación y llevar los datos a un back-end. Me resisto a tenerlo todo junto en único archivo, no es lo correcto.

El formato de la base back-end en principio es indiferente, siempre que no necesite instalar ningún driver ni herramienta auxiliar para su funcionamiento con la aplicación principal de Base.
Puedo instalar las herramientas necesarias para la creación de la base en otra máquina y luego copiarla al equipo de explotación que tiene los permisos de instalación bloqueados.

Saludos.

[Longi]

Buenas!
Echa un vistazo a esto:

https://forum.openoffice.org/es/forum/v ... 70&t=14905

Entendo qué muy sencillo no es, al menos por las explicaciones que doy.
También puedes mirar en el foro inglés :

https://forum.openoffice.org/en/forum/v ... 21&t=86071

A ver si hay suerte!

Un saludo!

[JoseJuan]

Gracias.
Voy a probarlo y te cuento.

[JoseJuan]

Muchas gracias por tu aportación. Un gran trabajo.
Se aparta de mis necesidades por lo que no lo puedo utilizar.

Te comento algunas sorpresas:
1-Formato: Esperaba que la bbdd back-end quedara encapsulada en un único archivo odb, como el que crea LO con HSQLDB embebido.
2-Front-end: Me ha costado localizar que es el mismo wizard el que se convierte en front-end, y mucho código incluido en él ya no será necesario.
3-Datos: Los datos son accesibles desde el front-end aunque no arranque el servidor, sin la macro inicial y sin ejecutar manualmente el bat de inicio.
4-Mulriusuario: Cuando acceden varios equipos a la bbdd todos deben iniciar el servidor?
5-Complejidad: Deberían integrarse los .bat en código de macro (SystemShellExecute), incluso localizar la ubicación del archivo java.exe

Resumiendo creo que llevo demasiado tiempo con ms-access, y veo obvios algunos procesos que no lo son tanto.
Seguiremos confiando que los desarrolladores de LO se tomen el Base más en serio, creo que somos muchos en esta situación.

Saludos.

[Longi]

Buenas de nuevo!
1- No tengo conocimientos de informática, sólo hago bricolage, por lo que quizá tenga, tengo los conceptos un tanto borrosos y mis palabras no serán suficientemente precisas.
Uno de los problemas fundamentales de base (HSQLDB1.8, no sé con Firebird) es la estabilidad o más bien la inestabilidad. La manera de sortearlo es evitando el efecto acordeón de la compresión/descompresión constante que se hace al abrir y cerrar el programa.
A día de hoy, lo único que he encontrado para poder tener separados los datos del motor es teniendo una carpeta con el motor por un lado y los datos en otra carpeta, por lo que, aunque sea en monopuesto, si se quiere separación, habrá carpetas, y si además se quiere multipuesto habría que usar un servidor (como lo que se anexó)
2- Con respecto al front-end (supongo que es lo que tenemos en la pantalla) es la solución que DCAM propuso, yo solo soy usuario, si bien es verdad que hice algunas modificaciones
3- Es cierto que se puede acceder a los datos sin arrancar el servidor, pero en ese caso solo sirve como una base de datos monopuesto ( no sé si eso es lo que realmente querías), y el título del hilo pone claramente 'Multiusuario'
4- No, el que inicia el servidor sería el que hace de 'Servidor', es decir, es el que regula el flujo de conexiones/desconexiones con las tablas que cada usuario quiere hacer. Todos los demás usarían una copia del front-end, pero no usarían el servidor, simplemente apuntan hacia el equipo que tiene el servidor, para que éste sea el que escribe en las tablas.
5- Me parece que sería lo lógico, pero ya digo, mis conocimientos dan para lo que dan, y en el modelo inicial se funcionaba arrancando el servidor por un lado y después la base de datos, lo que hice fue integrar ese arranque en la macro "Setup". Al estar escritos en Java (o eso creo) ni siquiera intenté integrarlos en el código Basic. No sé si se podrá, pero los autores creo que tinen algún conocimiento más que yo.
6- No estoy seguro de que todo lo que se explica al respecto sea claramente aplicable (ya digo, mis palabras pueden ser no realmente precisas, incluso los conceptos), pero si se puede mejorar algo (código o conceptos )serían de agradecer aportaciones al respecto.

Gracias!

[JoseJuan]

Hola,
Creo que tienes los conceptos bastante claros.
Según comentas, la macro Setup, localiza si hay alguna máquina ejecutando el servidor y la utiliza para enviar las actualizaciones a través de ella. Es correcto?
Que ocurre si la máquina que ejecuta el servidor se desconecta, el resto son capaces de seguir funcionando?
El proceso está suficientemente depurado para que otra máquina tome el control del servidor 'en caliente' sin intervención del usuario?

Me refería a integrar exclusivamente el .bat y ejecutar la orden que lanza el servidor ("%javapath%" -cp "%jarpath%" org.hsqldb.Server ...) desde la propia macro como si se tratara de una línea del Commnad Prompt, en lugar de tener que personalizar el .bat para cada aplicación.
Para ello previamente hay que buscar en el equipo la ubicación de los tres archivos, java.exe, hsqldb.jar y MiBaseDatos, que son las modificaciones que indicas.
-El primero estará en la carpeta 'Archivos de programa' del sistema.
-El segundo es el driver que podemos colocarlo nosotros, yo personalmente colocaría la subcarpeta del driver en una carpeta general, 'Archivos de programa', la principal de Java o la 'Common files'
-Por último la ruta de los datos, que podría ser una constante del código de la aplicación.
Si la búsqueda automática te resulta complicada, puedes recurrir a un archivo .ini conteniendo las ubicaciones y lo lees desde la macro, la idea es simplificar los archivos auxiliares, complicando el código de las macros.
Todo esto son solo ideas para una posible mejora.

En mi caso busco algo más sencillo, de momento no necesito que sea multiusuario, solo quiero la flexibilidad de tener los datos separados, aunque realmente accederán varios usuarios, solo uno de ellos actualizará datos. No debería usar una base de datos externa que utilice una estructura de varios archivos. En el futuro será mantenida por usuarios sin conocimientos y lo máximo a que puedo aspirar es la utilización de un GUI externo para su administración.

Saludos.

[Longi]

Buenas!
Echa un vistazo en https://wiki.openoffice.org/wiki/FAQ_(Base). Explican todo esto, pero en inglés.
Aquí te explican cómo conseguir dividir una base de datos embebida, sin necesidad de ser multiusuario.
El echo de estar en una carpeta aparte es para que si usas una base de datos monopuesto sea portable, y puedas llevarla de un PC a otro. Es cierto que la ruta de Java es la tuya, y que el driver se podría poner en otro lado, pero si no usas los bat (monopuesto), no precisas andar instalando nada en ningún sitio para empezar a trabajar (excepto el personalizar la ruta del Java).
En cuanto a si los demás pueden trabajar cuando tú (administrador/Servidor) estas apagado, decir que según está no, y no me imagino cómo sería, ya que se supone que el que inicia el proceso está en un PC (este arranca con los bat, arrancando el Servidor*). Todos los demás atacan al servidor encendido para leer/escribir en aquello que el Servidor pone a su disposición. Quizá sea esta la parte que menos clara dejé en la explicación. La macro "Setup" debe apuntar al PC que pone a disposición el servidor.

*Quiero suponer que si tienes la base de datos en una máquina que esté permanentemente encendida (máquina Servidor, no software) se podría hacer, pero una de las premisas con las que trabajé, y que expuse en el hilo es que me toca trabajar en una corporación en la que no permiten instalar nuevo software ( de ahí que no pueda descargar drivers de Firebird para hacerlo multiusuario, o los complementos de Firefox para SQLite, etc) y que el sistema de trabajo compartido es con carpetas compartidas dentro de una intranet. Por eso mi ordenador hace de máquina servidor, por eso todos los demás deben apuntar a mi pc y por eso, cuando lo apago deja de funcionar para los demás.
También supongo que si la base de datos la alojas en un servidor WEB se podría hacer, pero me pierdo totalmente.
En cuanto a las mejoras ya digo, todo lo propuesto será bienvenido, otra cosa es que sea aplicable al caso particular de cada uno.

Otro saludo!

[JoseJuan]

Hola.
He revisado el enlace y realmente la estructura de la base que se crea, es la misma que cuando se usa con el servidor HSQLDB, con varios archivos, nada intuitiva.
En este caso no se necesitan las macros de manejo del servidor y el front-end queda limpio de código.

Mi entorno de trabajo es muy similar al tuyo, donde tengo bloqueada las instalación de cualquier software.
La base de datos está ubicada en una carpeta de red, todo en un único archivo .odb, tablas, consultas, formularios e informes.
Actualmente lo usan tres personas que acceden al mismo archivo, a veces simultáneamente, aunque solo uno de ellos actualiza datos.

Estoy haciendo pruebas con SQLite que van por buen camino. Ya te cuento.

Saludos.

[Longi]

Es cierto que no es muy intuitivo.
Lo que hace que base sea 'intuitivo' en AOo y en LOo es precisamente que lo comprimen y le dan aspecto de un solo archivo, pero los archivos de ambas suites (a riesgo de meter la pata) son archivos comprimidos. Si coges una base de datos y le cambias la extensión a .zip, entonces verás que la estructura es precisamente de varias carpetas con código para las tablas, para los formularios, para los informes, etc, y luego, además, para los datos.
La diferencia es simplemente cómo lo vemos, pero la estructura es esa.
En su día intenté hacer una base de datos con Postgress y fui incapaz (tampoco es que le dedicase mucho tiempo al asunto), pero si te bajas Postgress verás que de intuitivo nada de nada, y que tiene la estructura en carpetas así repartida (que debe ser como funcionan todas las bases de datos, Base, simplemente lo camufla, y ese camuflaje es el responsable de la inestabilidad).
Antes de conseguir el multiusuario trabajé como tú indicas, pero con el problema de la inestabilidad. Después hice un Split, y la estabilidad apareció, pero tenía el problema de que varios quería escribir en ella, y lógicamente, cuando uno la usa, otro no puede. El problema surgía cuando uno la había usado, cerraba, pero no cerraba totalmente la suite (icluso matando el proceso soffice.bin), la base segúia bloqueada para el siguiente que quería usarla, y había que ir por los distintos ordenadores buscando al 'culpable'.
Esto no he sabido nunca si tiene arreglo o no, así que ahora, desde mi PC inicio el servidor con una versión de LO, mientras que el resto de las cosas las hago con otra versión. Así me aseguro que no voy a bloquear la base de datos con el resto de archivos que estoy manejando.
Incluso, cuando trabajo con la base, aunque abrí el servidor desde mi PC,uso otra instancia con la segunda versión de LOo para acceder a la base de datos, como que fuese un usuario más.
En cuanto a SQLite, RMG tiene experiencia, así que quizá él pueda echar una mano.

Otro saludo!

[RMG]

Hola JoseJuan.

Si puedes alojar el motor de BD SQLite en un servidor donde tengan acceso todos los usuarios, y en sus correspondientes PC, sí que pueden instalar los drivers ODBC de conexión a ella, esto es una buena solución. Por mi experiencia una de las mejores, no es multiusuario 100% por que no se puede atacar una misma tabla a la vez, pero si distintas tablas por los usuarios.

No necesitas nada más que esos drivers y las dos BD, .SQLite y .odb. En este enlace tienes los drivers, y dos aplicaciones para crear tablas, así como una pequeña explicación para hacer la conexión en Win. De las dos aplicaciones una se debe instalar, la otra simplemente es ejecutar el .exe, aunque yo suelo usar un complemento de Firefox llamado SQLite Manager para crear tablas y triggers. También debes hacer un par de cambios en las propiedades de la BD .odb para que en SQlite reconozca los tildes y las ñ, si estas interesado te lo puedo explicar.

https://mega.nz/folder/45VARAwL#fN3OiXtoVZ6pGCoGb1gPyQ

Saludos

[JoseJuan]

Gracias por la ayuda.
Una de mis limitaciones es la instalación, requiere permisos de administrador, que obviamente no tengo.
Así que no resulta posible instalar el driver ODBC para sqlite, que hubiera sido mi primera opción.
Estoy probando con JDBC, que no necesita instalación, solo descargar y añadirlo a las opciones Java de LibreOffice.

Puedo crear tablas y añadir registros desde le front-end de Base, pero ha surgido un problema, cuando Base hace cualquier modificación en los datos de una tabla, bien editando los datos (de bases ajenas enlazadas), o al finalizar la entrada de nuevos registros (tablas creadas por el fornt-end), la tabla se corrompe internamente sin dar error y cuando vuelvo a acceder a ella da el mensaje:
No se pudieron cargar los contenidos de los datos.
SQLite JDBC: internal inconsistent state

Los programas de administración de SQLite, SqliteAdmin y SqliteStudio, muestran correctamente las bases, sus tablas y sus datos, sin ningún problema pero desde Base ya no puedo ver los datos.
Tampoco he conseguido recuperara la tabla a un estado que los datos sean accesibles de nuevo, aun perdiendo las modificaciones.
Alguna idea?

Saludos.

[RMG]

Hola,

Quizás no te haya entendido bien. Veamos si es correcto lo que entiendo que quieres hacer, tengo que decir que esto no lo he hecho nunca, por lo que no se si es posible.

Tienes un servidor (PC) donde no puedes instalar nada, pero si puedes alojar una BD SQLite con sus tablas (datos) .
Tienes varios PC que si puedes instalar drivers ODBC y tienes en cada uno una BD Base (.odb como interfaz) y tienen acceso al servidor.
Al hacer la conexión ODBC de Base a SQLite en cada PC, le indicas la ruta donde esta la BD SQLite situada en el servidor.
Esto último es donde tengo dudas, si tampoco puedes instalar drivers en los PC donde tienes Base?.

Como te digo esto nunca lo he hecho, pero si puedes instalar drivers en los PC con la BD Base, creo que si puedes hacer la conexión.

Ya me dices si es correcto lo que digo.

Saludos

[JoseJuan]

Hola,
En general vas bien, lo has entendido casi todo. Con este sistema la base sqlite no necesita servidor, solo LibreOffice y JDBC (no ODBC).

Te cuento los detalles, en lugar de un PC servidor tengo una ubicación compartida de red donde se aloja la base sqlite, en un único archivo, que hace las funciones de back-end.
Por otro lado tengo varios Pc's, que tienen LibreOffice instalado y configurado el driver JDBC que no necesita instalación. También tienen todos acceso a la carpeta de red.
Estos Pc's trabajan como front-end ejecutando una 'aplicación' en Base que tiene enlazada la bbdd sqlite.

Estoy con las pruebas iniciales en un Pc.
La base de datos se crea y mantiene directamente desde los Pc con Base. Cualquiera de ellos podrá actuar como administrador de la bbdd, supongo que será cuando trabaje en exclusividad.
El driver de JDBC que estoy utilizando es el xerial 3.30.1 y puede que no este afinado para LibreOffice 5.3.7.2, tengo que probarlo con la 6.
Está funcionando salvo el pequeño problema que te he comentado arriba, luego ya veremos la estabilidad.

Cuando lo tenga acabado, os escribiré un paso a paso.

Saludos.

[JoseJuan]

Hola,

Después de muchas pruebas he conseguido delimitar un poco el problema que tengo en Base con SQLite: SQLite JDBC: internal inconsistent state
Por extraño que parezca, las tablas de SQLite a través de JDBC funcionan bien en Base cuando alcanzan los 42 registros, si, si, exactamente 42, con menos registros siempre da el error.
Esto es independiente del número de campos que tenga la tabla, de sus tamaños y de los datos que contengan.
Cuando uso los administradores de bbdd para sqlite no tengo ningún problema, con cualquier número de registros.

Alguien puede orientarme con este extraño error?
Gracias.

Saludos

[Longi]

Buenas!
No voy a solucionar absolutamente nada, pero acabo de encontrar una coincidencia con el número 42.
En los formularios, si no se hace nada especial, cuando se abren, en la esquina inferior izquierda hay un recuadro donde te dice en qué registro estás, y te pone 'Registro 1 de 41*'
He estado imitando este indicador con una macro tras del cambio de registros en el formulario por diversos juegos que estoy haciendo, y donde pone 41* lo he imitado con oForm.RowCount, e indefectiblemente me coloca 42 registros, hasta que llego allí, y después me pasa a 63.
Lo solventé con un ResultSet a partir del form.command, y yendo al último registro y cojo el número de fila que está al final.
La conclusión para tu caso es que debe estar relacionado con el manejo de los ResultSet en la parte interna de AOo o LOo, ya que es curioso que se atasque en el 42 el contaje de filas del formulario, cuando en realidad el número de registros totales es muy superior.
¿Cómo hacer?, ni idea, simplemente me resultó curiosa la coincidencia del número que tú indicas y lo que me acabo de encontrar.

Un saludo!

[JoseJuan]

Muchas gracias.

Al parecer tiene que ver con la carga de la página de datos.
En los formularios te permite tratarlo con código, pero mi problema es con las tablas y no se trata de un numero al pie, me da un error grave y no permite abrirlas, ni acceder a ellas con formularios hasta que no alcanzan el número mínimo de 42 registros.
Cuando abro una tabla con muchos registros, me indica al pie 1 de 101*, pero si accedo a esa misma tabla con un form, también me indica 1 de 41*.

Desconozco si esta conexión JDBC-sqlite permite añadir parámetros como se hace con JDBC-HSQL (default_schema=true;shutdown=true;hsqldb.default_table_type=cached;get_column_name=false), las pruebas que he hecho a la desesperada siempre daban error

Estoy comenzando a pensar que será un bug del JDBC. El único que he probado es de xerial.org en distintas versiones, el de Zentus ya no está disponible. Conocéis algún otro driver JDBC para sqlite?
Siempre puedo añadir 41 registros falsos a todas las tablas y luego filtrarlos. je je.

Saludos.