Buenas!
Lo he complicado todo un poco….El ejemplo lo pongo en HSQLDB 2.3 multiusuario, así también si alguien quiere probar, tiene la posibilidad.
En la carpeta van tres .bat que tendrían que ser editados con la ruta de ‘Java.exe ‘y con la ruta en la que se ponga la carpeta (traduje algunas líneas explicativas de cómo y para qué hacer las cosas).
Al abrir la base de datos ya arranca el servidor sin más problemas (o así debiera ser).
Al abrir, se lanza el formulario denominado ‘Formulario_puente’, que tiene como formulario principal un cuadro de lista.
Si te sitúas en uno de los DNI y le das al botón ‘Búsqueda’ no pasará nada (se ha colocado en el primer registro que tiene el DNI que le has marcado, y como viene en el diálogo por defecto, no parece haber hecho nada). Si vuelves a clickar en ‘Búsqueda’ irá al siguiente registro que tiene ese DNI, y así hasta terminar los registros, mostrándote un aviso de que no le quedan más.
También avisa si no hay registros con el texto solicitado (que por supuesto puedes cambiar).
Este formulario tiene un formulario principal en forma de control de tablas con origen un SQL, pero no tiene orden ni filtro en las condiciones del formulario. Así funciona sin problemas.
En el otro formulario (Formulario_puente3) sí que le he puesto filtro y orden, y ya no funciona.
Entre las pruebas que he hecho está que si en el formulario ‘esclavo’ uso el form.Command y le pregunto el número de líneas, entonces me da tantas como la tabla de origen (oSQL o Consulta, según el caso), pero si utilizo el ‘oForm.CreateResultSet()’ y le pregunto como a un resultSet normal y corriente, tendré una respuesta de 1 ó unos pocos según los registros relacionados con el ‘formulario Master’.
No había explicado que en la técnica usada (no se me ocurrió mejor cosa) genero dos consultas una tras de otra, con la idea de numerar cada registro del formulario con su número de registro en la tabla original (función ROWNUM() que sí que existe en HSQLDB 2.3 y creo que en Firebird, pero no en HSQLDB 1.8). De tal modo que, el resultSet con el que se genera el formulario me dará una consulta con todos los registros del formulario y en el orden en el que están.
La segunda consulta, con la función anterior y usando a la anterior consulta como origen de datos me da una lista con el primer campo ocupado por un dígito, que corresponde con el número de línea que tendría sin atender al orden (no termino de entender el porqué, pero parece que es así).
Después en el código meto otro SQL con la función de marras y me termina dando un listado para el texto escogido con un primer campo que indica el número de línea del resultSet en el que tendríamos que fijar el formulario . Tendremos tantas filas como registros hay para el texto propuesto.
Complejo de seguir ¿no?, pues todo esto se desmorona en cuanto aparece un filter o un order en las propiedades del formulario, así que pensaba si habría posibilidad de escalar el ‘oForm.CreateResultSet()’ para conseguir una expresión SQL que incluyese todos los condicionantes para poder hacer las consultas sin más error.
De todos modos, esto creo que no es para mí, que os estoy dando guerra por algo que no puedo abarcar, y que si alguien tiene que entrar al trapo son los ‘LOOMakers’, que creo que ya que están de cambios en base, podríamos abrir un hilo sobre propuestas de mejora para que alguien con mejor criterio que el mío seleccione las razonables y se las envíe a quien tengan que ir.
Perdón por el rollo, gracias y un saludo!
El arhivo se hace algo grande así que se puede bajar de aqui:
https://drive.google.com/file/d/1H91Y4T ... sp=sharing
PD. Si queda sin contestar no me parecería extraño.
