Description: Hello, When creating a query in the SQL-view, sometimes the code looses all linebreaks. The functionality isnt affected, but its very hard to work with the code without linebreaks. This happens only if the mode is set to not execute the query directly on DB. It might has something to do with the automatic check / supplement of quatation marks around table and column names (e.g. tbl_A.x gets "tbl_A"."x"). I could experience this behavior on GNU/Linux (Debian with KDE) and Windows 10 in several versions of LibreOffice up to 25.2.3.2. Steps to Reproduce: 1. Create a query in SQL view with linebreaks and tabs etc. 2. Set Mode to directly execute on DB and save query 3. Close and reopen query in SQL-view Actual Results: The SQL code has no linebreaks and no tabs Expected Results: The SQL code should be in the same format as it was shown when saved. Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Debian package version: 4:25.2.3-2+deb13u2 Calc: threaded
SQL code, which could be executed through GUI, won't be saved with any formatting. This will only be possible if setting "Execute in direct SQL" when editing the query in SQL. Reason: The GUI will be used for creating SQL, not the SQL editor. Every time the GUI will be opened for changing anything in a query it will also change the code (remove 'AS' for example). Only code, which will be executed directly, won't be interpreted and changed by GUI. The behavior you reported is the default behavior. Don't know if we could set is as a bug. But it's a real feature request. So I will set this one to NEW, the version to the earliest affected (Inherited by OOo) and the importance to enhancement.
If we talk about the "Execute SQL statement" dialog and specifically the "command to execute", line breaks aka \n are indeed "normalized" in DirectSQLDialog::implAddToStatementHistory() (but kept for the previous commands, see bug 140298). Skimming over these lines the internal history seems to be the reason. Further improvements might be feasible.