Description: Our application uses HSQLDB database with external server process. Using LO v7.2.0.4, clicking on a database table owned by PUBLIC shows no records. Using a table owned by non-PUBLIC user shows all records as expected. Steps to Reproduce: 1. Open BASE app with tables owned by PUBLIC and non-PUBLIC users. 2. Open table owned by non-PUBLIC user, verify records displayed 3. Open table owned by PUBLIC user Actual Results: No records displayed Expected Results: All records displayed Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
@Andrew : did this work correctly in a previous version of LibreOffice ? How do you manage the difference between PUBLIC and non-PUBLIC users with regard to schema access ? Can you give us an example of the connection string entered in the ODB JDBC driver configuration (obviously anonymizing any credentials or IP addresses, if any) ? Can't test on macOS, unfortunately, changing the JAR for server access hoses the access to my existing embedded hsqldb files.
Created attachment 175035 [details] HSQLDB *.script file (redacted) The *.script for for the external database. Note all persistent database objects are created under schema "PUBLIC". Temporary tables are under non-"PUBLIC" schemas.
@Alex, this bad behavior seems to have been introduced in the LO 7.x releases. I cannot say exactly when it first appeared. I developed our application using LO 6.x, and used the table record viewer extensively at this time. Only on doming recent maintenance did I discover the bad behavior. I have uploaded the HSQLDB *.script file so you can clearly see how the database objects are defined. I suspect this my be related to object ownership/privilege's as the viewer works fine for objects owned by the current user. Here is the JDBC connection string (using localhost instead of true IP address). jdbc:hsqldb:hsql://localhost/boars I see this problem on both Windows and MacOS environments.
I verified the following LO version does NOT have this issue, "PUBLIC" tables content is displayed as expected. So something changed in the LO 7.x timeframe. Version: 6.4.7.2 (x64) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Quieres comprar Cama nido 135x190? ¡Encuentralos aquí! ✓ Todo en stock y envío rápido. Si buscas comprar muebles online al mejor precio, esta es tu tienda. https://lamundial.net/camas-nido-135-x-190/
(In reply to Andrew Richardson from comment #4) > I verified the following LO version does NOT have this issue, "PUBLIC" > tables content is displayed as expected. So something changed in the LO 7.x > timeframe. > > Version: 6.4.7.2 (x64) > Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 > CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: GL; VCL: win; > Locale: en-US (en_US); UI-Language: en-US > Calc: threaded Marking as regression. Would now be nice to get a bibisect of the bug - https://wiki.documentfoundation.org/QA/HowToBibisect Please could you do it?
Adding Cc: to [Caolán McNamara <caolanm@redhat.com>] Used bibisected repository 'win64-7.1' 8f7d2cf5680cebb07bc15b075d491a7e0fd6c0d9 is the first bad commit commit 8f7d2cf5680cebb07bc15b075d491a7e0fd6c0d9 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Aug 12 12:45:10 2020 -0700 source 46c34d5abcc3fb709de4c3a6a62649f1fe41ec9c source 46c34d5abcc3fb709de4c3a6a62649f1fe41ec9c instdir/program/dbulo.dll | Bin 4854272 -> 4878848 bytes instdir/program/setup.ini | 2 +- instdir/program/version.ini | 2 +- instdir/share/config/images_breeze.zip | Bin 1868964 -> 1868964 bytes instdir/share/config/images_breeze_dark.zip | Bin 1864637 -> 1864637 bytes instdir/share/config/images_breeze_dark_svg.zip | Bin 1551286 -> 1551286 bytes instdir/share/config/images_breeze_svg.zip | Bin 1548846 -> 1548846 bytes instdir/share/config/images_colibre.zip | Bin 2741947 -> 2741947 bytes instdir/share/config/images_colibre_svg.zip | Bin 2820305 -> 2820305 bytes instdir/share/config/images_elementary.zip | Bin 4026203 -> 4026203 bytes instdir/share/config/images_elementary_svg.zip | Bin 5009132 -> 5009132 bytes instdir/share/config/images_karasa_jaga.zip | Bin 4839439 -> 4839439 bytes instdir/share/config/images_karasa_jaga_svg.zip | Bin 19241572 -> 19241572 bytes instdir/share/config/images_sifr.zip | Bin 2078977 -> 2078977 bytes instdir/share/config/images_sifr_dark.zip | Bin 2080851 -> 2080851 bytes instdir/share/config/images_sifr_dark_svg.zip | Bin 1730890 -> 1730890 bytes instdir/share/config/images_sifr_svg.zip | Bin 1727091 -> 1727091 bytes instdir/share/config/images_sukapura.zip | Bin 3011393 -> 3011393 bytes instdir/share/config/images_sukapura_svg.zip | Bin 4307058 -> 4307058 bytes .../config/soffice.cfg/dbaccess/ui/dbtreelist.ui | 94 +++++++++++++++++++++ 20 files changed, 96 insertions(+), 2 deletions(-) create mode 100755 instdir/share/config/soffice.cfg/dbaccess/ui/dbtreelist.ui
Looking at the source commit, I suspect the issue is in OTableTreeListBox::getQualifiedTableName(). If "bSchema" is false, this may give rise to the symptoms observed. Just a guess, but might help developer narrow down source of problem.
how to reproduce this though? I got as far as downloading hsqldb-2.7.0.jar and the BOARS.script and search-replace --REDACTED-- with "test" and java -cp ../hsqldb-2.7.0.jar org.hsqldb.server.Server --database.0 file:BOARS but that just fails with [Server@1b2c6ec2]: [Thread[HSQLDB Server @1b2c6ec2,5,main]]: Database [index=0, db=file:BOARS, alias=] did not open: org.hsqldb.HsqlException: error in script file line: 98 org.hsqldb.HsqlException: java.io.EOFException
Created attachment 181508 [details] Screen capture showing table tree in working version
Created attachment 181509 [details] Demo BASE file demonstrating bad behaviour Created a Demo BASE file with an embedded database demonstrating bad behaviour. The tree of tables is NOT displayed with the different schemas shown as parent nodes. All tables can be opened EXCEPT for "TEMP_CAMP_DETAIL", which is owned by a non-PUBLIC schema. Suspect fixing the root cause of bug will allow all tables to be opened. Expected behaviour is the tree view will show every schema name, then all table names within that schema as children nodes. For the Demo case, the schemas are "PUBLIC" and "BOARS_USER1". Under "BOARS_USER1", only "TEMP_CAMP_DETAIL" should be listed. All other tables would appear under "PUBLIC" schema.
comment #4 and #7 suggest that version 6.4 was ok but the embedded example of comment #11 seems to work the same then as now with no hierarchical view so I can't reproduce with something that gives an original working case with 6.4
I have not found a way to setup a Demo embedded database which displays the "catalog->schema->table" tree view, and I cannot send you to entire server database where this does appear due to data privacy reasons. There was an earlier comment of problems using a server database so this may not be an avenue worth pursuing. In the available Demo file, you can see the table names appear as a flat list. There is no catalog or schema parent structure shown. You can click on any table name 'owned' by PUBLIC schema, and the edit spreadsheet view will open successfully. Click on the single TEMP table owned by non-PUBLIC schema, and there is an immediate error message. I suspect there is a flaw in the object name query logic. Clearly it should not matter the schema, the edit view should be available for any table object (subject to access constraints).