[Resuelto] Evitar que LibreOffice Base modifique SQL

[Urxvt]

Buenas tardes.

El otro día me encontré con que LibreOffice Base había modificado ligeramente la sentencia SQL de una consulta. Deduzco que lo hace cada vez que se edita una consulta en modo normal y se guarda, entonces reescribe el SQL, y aunque haya modificado simplemente un alias, lo reescribe todo y lo formatea en una sola línea. Pero esto tiende a provocar fallos en una consulta compleja y me disgusta enormemente, así que prefiero usar únicamente el editor SQL.

Y por otra parte, si uso siempre el editor SQL, al guardar y abrir sí que se mantiene la sentencia, pero igualmente queda formateada en una sola línea.

La pregunta es: ¿Existe la posibilidad de evitar/desactivar que LibreOffice Base modifique el SQL de las consultas?

Gracias de antemano y un saludo.

[fornelasa]

Considero que no hay manera de evitarlo de forma automática.
¿Tendrás a la mano un ejemplo en donde se note eso que comentas?
Saludos, Federico.

[Urxvt]

Tengo esta consulta, y el agrupador por año quedó "roto" y nos dio algún susto en facturación... Esto sucedió después de abrir el editor de consultas, modificar algo irelevante y guardar:

Código: Seleccionar todo   Expandir vistaContraer vista

SELECT YEAR("Jornada") AS "Any",
       QUARTER("Jornada") AS "Trimestre",
       "Tasques"."ID_Treball" AS "ID_Treball",
       "Tasques"."ID_Treballador" AS "ID_Treballador",
       "PreusAnuals"."PreuHora" AS "Preu hora",
       "PreusAnuals"."PreuKm" AS "Preu km",
       SUM("Tasques"."Hores") AS "Total hores",
       SUM("Tasques"."Kms") AS "Total kms",
       SUM("Tasques"."Extres") AS "Total extres",
       SUM("PreuHora" * "Hores") AS "Cost hores",
       SUM("PreuKm" * "Kms") AS "Cost kms",
       COALESCE (SUM("PreuHora" * "Hores"),
                 0) + COALESCE (SUM("PreuKm" * "Kms"),
                                0) + COALESCE (SUM("Extres"),
                                               0) AS "Cost total"
FROM "Tasques",
     "Treballadors",
     "Treballs",
     "PreusAnuals"
WHERE "Tasques"."ID_Treballador" = "Treballadors"."IDTreballador"
  AND "Tasques"."ID_Treball" = "Treballs"."IDTreball"
  AND "PreusAnuals"."ID_Treballador" = "Treballadors"."IDTreballador"
  AND "PreusAnuals"."Any" = YEAR("Tasques"."Jornada")
GROUP BY YEAR("Jornada"),
    QUARTER("Jornada"),
         "Tasques"."ID_Treball",
         "Tasques"."ID_Treballador",
         "PreusAnuals"."PreuHora",
         "PreusAnuals"."PreuKm"
ORDER BY "Any" ASC,
         "Trimestre" ASC


Por otra parte, así es como tengo la sentencia SQL formateada y me es más cómodo de leer y editar, pero al guardar se recompone en una única línea.

Está previsto para LibreOffice 6.2 usar Firebird como motor de bases de datos, y dejarán HyperSQL-DB, aunque lo mantendrán para no obligar a migrar. No sé si ese cambio puede ser debido a algún tipo de bug, más allá de la eficiencia como motor. Estaría bien saber si hay bugs conocidos en esta parte. Pero esa decisión creo que sólo la saben los propios desarrolladores.

[fornelasa]

Por otra parte, así es como tengo la sentencia SQL formateada y me es más cómodo de leer y editar, pero al guardar se recompone en una única línea.

¿No te servirá algo similar a:?

Código: Seleccionar todo   Expandir vistaContraer vista

SELECT * FROM "Tabla" _
WHERE "Campo" = 'FEDERICO'

Por favor nota el espacio y el guión bajo, parece que libre lo respeta de ese modo, es decir por ejemplo:

Código: Seleccionar todo   Expandir vistaContraer vista

SELECT YEAR("Jornada") AS "Any", _
       QUARTER("Jornada") AS "Trimestre", _

[Urxvt]

Estaría bien así, tal y como dices, terminando las líneas (menos la última) con " _". No obstante me devuelve error de sintaxis. A lo mejor es por la versión (5.2.7.2).

[fornelasa]

En mi versión de LO acepta correctamente el espacio y el guión bajo.
¿La coma es necesaria?
¿Por ejemplo así:?

Código: Seleccionar todo   Expandir vistaContraer vista

SELECT YEAR("Jornada") AS "Any" _
       , QUARTER("Jornada") AS "Trimestre" _
       , wwwwwwwwwwwww

[Urxvt]

Entonces seguro que es por la diferencia de versión. Por cierto, en las macros sí que me permite usar el espacio y la barra plana, así siempre procuro no hacer líneas demasiado largas.

Lo que haré entonces es guardar las sentencias SQL en archivos independientes en un directorio con git, así de paso tendré control de versiones y en caso de modificar algo siempre podré consultar y comparar entre ficheros. Y lo mismo con las macros, ya puestos, jeje. Pero me ayuda mucho saber que es posible hacer lo que comentas. Bajaré una AppImage del LibreOffice más actualizado y haré pruebas con eso. Gracias!

Pongo el tema como resuelto, entonces.

[fornelasa]

Si, parece que la clave esta en el espacio y el guión bajo:
Vamos a suponer que tengo una tabla llamada exactamente Empleados
En mi versión de LO funciona correctamente la siguiente estructura

Código: Seleccionar todo   Expandir vistaContraer vista

SELECT CAMPO1,
CAMPO2,
CAMPO3 FROM "Empleados" _
WHERE "CAMPO1" = 'FEDERICO'

respetando exactamente cada linea.

En este caso da error:

Código: Seleccionar todo   Expandir vistaContraer vista

SELECT CAMPO1,
CAMPO2,
CAMPO3 FROM "EMPLEADOS" _
WHERE "CAMPO1" = 'FEDERICO'

[Longi]

Perdón por mi miopía, pero la única diferencia que veo entre una y otra es que el nombre de la tabla en una está en mayúsculas y la otra en minúsculas (lo cual sería suficiente para dar error), pero no he visto diferencias en el tema de los espacios o los guiones bajos.


Un saludo!

[fornelasa]

Exacto coincido contigo longi.
Se intentó decir que LibreOffice respeta correctamente la estructura de una instrucción SQL aunque ella esté segmentada en varias líneas.
Urxvt comenta que al guardar su instrucción SQL (que esta segmentada en varias líneas) el programa las une en una sola y él desea que al salvar dicha instrucción respete tales segmentaciones.
¿Cómo podemos solucionar lo anterior?
Sugerencias:
1) Utilizando el espacio y el guión bajo
2) Poniendo atención en los detalle de la consulta como por ejemplo el que la tabla sea escrita de forma correcta, respetando si se puede mayúsculas o minúsculas.
3) Etc.