When opening forms with subforms the following error is produced:
SELECT * FROM "projekte"."nationalisierungen" WHERE ( "projekte"."nationalisierungen"."pID" = :link_from_str_ID ) ORDER BY "Land" ASC
nationalisierungen is a table included in the form as subform by linking its field pID to the field str_ID of the main table/form.
"pID" = :link_from_str_ID does not seem to be standard SQL and throws the error.
Base is connected to a MariaDB (10.1.44 Ubuntu 18.04.1) via libreoffice-mysql-connector (6.4.3-1)
Steps to Reproduce:
1. Open form with subforms.
Subform fields are not populated with data.
Subform fields/tables should be populated with data
User Profile Reset: No
Could you try to run this macro here:
and give a new try?
Indeed, I think it may be related to a variable "ParameterNameSubstitution" set to "false".
Running the Macro solved the problem. Subforms load data nicely now. Thank you!
I forgot to mention, that the same Base file / MariaDB database connection under LO 6.0.7 (Ubuntu 18.04) was working just fine.
Therefore, additional people upgrading now from ubuntu 18.04 to 20.04 might also encounter this problem.
First, could you rename your LO directory profile? (see https://wiki.documentfoundation.org/UserProfile#GNU.2FLinux)
Then would you be able to generate a brand new odb file with this problem?
If yes, could you provide minimal step by step to reproduce this?
It may to investigate how to fix this.
Indeed, it seems that even for brand new files, we may encounter the pb.
*** This bug has been marked as a duplicate of bug 118112 ***
No, I could not reproduce the bug with a new base file:
1. renaming profile (e.g. new user folder will be created)
2. creating new base file
3. connecting to database with mysql native driver
4. creating a form using the form assistant
- using the tables mentioned before
- including a subform with the mentioned relationship
-> Works fine
Ok so if it's specific to this file, would it be possible you attach a script to create Mysql database with tables + attach files to try to reproduce this?
Or perhaps you could recreate the whole file from scratch and it works now so no need to investigate?
For new files this does not seem to be a problem.
For old files your macro solves the problem.
My base file is very old (e.g. has been continuously developed and expanded since 2004/2005). In the version jumps from 6.0 to 6.4 there seems to be some incompatibility. What this exactly is and what your macro changes, I do not understand.
Ok so no more pb for you.
Interesting too to know that a brand new odb file doesn't need the macro.