Description: I changed to firebird database and all "find column" statements in the basic functions fails with "column name nor exist". Steps to Reproduce: 1. make a select and use alias for columns with arithmetic or case constructs 2. call the select statement in basic and get the value in the result with find column and the alias name 3. result is an basic runtime error Actual Results: result is an basic runtime error Expected Results: the alias names must get as names for the column in the result set Reproducible: Always User Profile Reset: No Additional Info: I make a new database on my laptop (normally working with my PC) to resolve the bug
Created attachment 160612 [details] test database with test formular open database, open formuar and press copy.
(In reply to heinz@hjb-seite.de from comment #1) > Created attachment 160612 [details] > test database with test formular > > open database, open formuar and press copy. Do you mean, 1. Open database. 2. Open Forms 3. Copy Form ?
1. Open database. 2. Open Form 3. Click on button to start basic 4. Basic function try to copy records from table to table
Reproduced in Version: 7.0.0.0.alpha1+ Build ID: 86bc13248c1d9f63b10aac304bdf0361d1dcc47f CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded and Version: 6.2.0.0.alpha0+ Build ID: 41d8ca9686c7c184f586e99674b443c34bfd4f33 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: threaded
On pc Debian x86-64 with master sources updated today, I could reproduce this. I created a new form by using the existing query "address" and no pb. Do you reproduce this with embedded hsqldb?
I create the an empty db with embedded hsqldb and then migrate to firebird. Then I create the tables and the form. I migrated the database for my club administration to firebird and caught problems. Btw, as workaround I replaced all findColumns with names by getByIndex.
Since Firebird is experimental, I'd advise to stick to hsqldb for the moment. Could you attach the initial hsqldb file after having sanitized (see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission) if necessary?
The attached "test database" only contains test data to demonstrate the bug. The way back to hsqldb is too much work.
Thought you had kept the original embedded hsqldb file. Thank you for your feedback. I'm uncc myself since I won't be able to help here.
I have tested this a little bit. if connecting to the query and reading the command with a macro I get Tabelle : T( 0 To 6 ) As string (0) | string : "ADD" (1) | string : "CONCATENATION" (2) | string : "Vorname" (3) | string : "CONCATENATION1" (4) | string : "CONCATENATION2" (5) | string : "PLZ" (6) | string : "Nummer" If you connect the query directly to the form the fields will be shown with the right alias.
Testing with: Version : 6.4.4.2 Build ID : 3d775be2011f3886db32dfd395a6a6d1ca2630ff Threads CPU : 8; OS : Mac OS X 10.15.5; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Confirmed with that version as well.
*** Bug 133823 has been marked as a duplicate of this bug. ***
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4590048952a9e62124641c512dc2d19122f7fb2d tdf#132924 - Firebird findColumn: return column alias if specified It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I test with version 7.5.4.2 and the bug ist fixed. The alias names in the sql-statement are correctly used in the macro script.