When using functions with aliases in an SQL command to set the data source for a new (sub)form, the alias won’t show in the list of applicable attributes when assigning data to a field / column. Instead the used function is shown. Steps to Reproduce: 1. Create new form in Design View 2. Create new form in Form Navigator 3. At Data > Content Type in Form Properties choose SQL command 4. Use any function with an alias in the select statement 5. Create a Table Control or other field 6. Insert new column and assign data from list Actual Results: The list won’t show the alias but instead the used function, p.e. ADD / CONCATENATION / CONCATENATION1 / SUM / etc. Expected Results: Show the aliases in the list Additional Info: There is a work around. First create a query with the same SQL command. Then use this query as the data source instead of the SQL command Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-IE (en_IE); UI: en-GB Calc: threaded
Would be good to provide an example here. Have tested this: Table with on field, which is INTEGER. SQL in the form: SELECT "ID", "ID" * 3 AD "triple" FROM "Table" If I choose a form control I will get "MULTIPLY" for this field with internal Firebird. Will be "triple" with internal HSQLDB. If I choose "Field add …" of the toolbar for creating forms there will be shown "triple". The alias will be also ignored for other fields, not only for fields, which contain a function. You could write SELECT "Name" AS "Forename" From "Table" and "Name" will be offered for selection in the controls. This is a special bug of internal Firebird database. Tested with OpenSUSE 15.3 64bit rpm Linux and LO 7.3.1.3.
Wondering if it could be related to Bug 132924 and Bug 132924, although those ones are about column aliases.
Tested this again. Couldn't reproduce the bug with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 59cb37a210675d4269c2fcd48feeffe942538891 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Should we close this one as WORKSFORME?
(In reply to Robert Großkopf from comment #3) > Tested this again. Couldn't reproduce the bug with > Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 59cb37a210675d4269c2fcd48feeffe942538891 > CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) > Locale: de-DE (de_DE.UTF-8); UI: de-DE > Calc: threaded Also tested with --------- Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-UY (es_ES); UI: es-ES Calc: CL threaded -------- Can't reproduce > Should we close this one as WORKSFORME? Yes, I think so, so as @Robert suggests I close the bug with WORKSFORMEW