In database application : Tools/ Filter tables I am used to filter database tables (Oracle datebase accessed with Oracle JDBC). In previous versions of Base, i can check the tables i want to see. This feature does work in LibreOffice.org 4.0.4, i can check the database tables but after pressing OK, no filter remains and no table appears.
Is this specific to having an Oracle db or is it the same for any database that allows filtering ?
Confirming on OSX 10.10.2 LO master Version: 4.5.0.0.alpha0+ Build ID: 48f704c3e1c08ae6e3eee450bf08712dc4caf460 Locale: fr_ Tested against a remote mysql db instance with default access to all tables. Opened ODB Click on Tables button in left hand pane. Enter password. Then menu Tools > Table filter Deselect all databases but one. The remaining selected database contains approx 15 tables. Click OK Menu View > Refresh tables All tables disappear ! Including the database I hadn't deselected.
The second time I did this, while writing the comments below to describe what I did, LO SIGABRTs on me, enclosing crash trace produced by Apple.
Created attachment 113093 [details] Apple crash trace
Confirming also with a jdbc connector to remote mysql instance - all the tables disappear when refresh tables is executed. The crash comment in comment 3 can be ignored - this is due to a breakdown in network connection between the two machines, for which I've already reported the bug. In my JDBC test, the connection parameters are set up to connect to only 1 database - from the menu Tools Table filters, I deselected a few tables, clicked on OK, then went to to View > Refresh tables. All tables suddenly disappeared. If I go back into the Tools > Table filter menu entry, there are no databases displayed, much less any tables, the whole window is blank.
Table filter works in Version: 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
Already failing in Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
@Caolan : UI rework related ?
(In reply to Alex Thurgood from comment #8) > @Caolan : UI rework related ? Yes, exactly.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f40b11f901d440b6d259c5c030d78f1ac2705647 tdf#89070 Table filter dialog: properly initialise OTableTreeListBox It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel: I updated my local master repo and it indeed works but only when relaunching LO. I mean, the filter is taken into account right away in dialog (you can close and reopen the dialog, it's ok) but not for showing tables. Is it another bug or does it correspond to an existing bug?
(In reply to Julien Nabet from comment #11) > Lionel: I updated my local master repo and it indeed works but only when > relaunching LO. I mean, the filter is taken into account right away in > dialog (you can close and reopen the dialog, it's ok) but not for showing > tables. > > Is it another bug or does it correspond to an existing bug? Well, let's say at least it is not a regression because it was always like that, as far as I can remember. To apply the new filter, one has to do "Refresh Tables". Doing it automatically after closing the dialog is indeed not a bad idea.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1876ec092382beb8b3d6a9b9fb4dfe3148d758a6&h=libreoffice-4-4 tdf#89070 Table filter dialog: properly initialise OTableTreeListBox It will be available in 4.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So, I have just tried this on master Version: 4.5.0.0.alpha0+ Build ID: f5e7207053b857b6903a0ab9c161bed9ad7bcee9 Locale: fr_ While the tables do now disappear after a table refresh, if I deselect the a whole set of table for a given schema at the highest level in the tree, the schema entries do not - aren't they supposed to disappear as well ?
(In reply to Alex Thurgood from comment #14) > So, I have just tried this on master > Version: 4.5.0.0.alpha0+ > Build ID: f5e7207053b857b6903a0ab9c161bed9ad7bcee9 > Locale: fr_ > > While the tables do now disappear after a table refresh, if I deselect the a > whole set of table for a given schema at the highest level in the tree, the > schema entries do not - aren't they supposed to disappear as well ? Did you deselect the schema entry itself?
(In reply to Lionel Elie Mamane from comment #15) > > Did you deselect the schema entry itself? Yes Additionally, there seems to be a problem re-selecting tables that were previously removed. 1) Open ODB 2) Tools > Table filter > Select tables to filter out > OK 3) Display > Refresh tables > selected tables are now no longer displayed 4) Tools > Table filter > select tables to include > OK 5) Display > Refresh tables > display remains unchanged, the newly selected tables are not displayed. Seems the fix is incomplete ?
(In reply to Alex Thurgood from comment #16) > (In reply to Lionel Elie Mamane from comment #15) > > > > > > Did you deselect the schema entry itself? > > Yes > Additionally, there seems to be a problem re-selecting tables that were > previously removed. > > 1) Open ODB > 2) Tools > Table filter > Select tables to filter out > OK > 3) Display > Refresh tables > selected tables are now no longer displayed > 4) Tools > Table filter > select tables to include > OK > 5) Display > Refresh tables > display remains unchanged, the newly selected > tables are not displayed. > > Seems the fix is incomplete ? Just ot be absolutely clear, because I realise that my use of the word "select/deselect" is not particularly obvious : Step 2 : untick box against tables/schema to remove Step 4 : tick box against tables/schema to include
Testing on a different database file with a mysql JDBC connector, if I untick a table within a schema, then refresh the table list, then return to the Table filter dialog, the previously unticked table no longer even appears in the list...so I can't bring it back, even if I wanted to. At least with the native mysql connector I could re-tick the box against the previously removed table, even if that had no actual effect.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=120f748e81aefa863d6c425b85563dbbb70ae4c1&h=libreoffice-4-3 tdf#89070 Table filter dialog: properly initialise OTableTreeListBox It will be available in 4.3.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tested Version: 4.5.0.0.alpha0+ Build ID: 1d85cf3504f5dcbbf0ae017eee47fc5a302a2739 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-02-21_00:41:48 Locale: fr_FR Reopening as one can not bring back removed tables, even if one goes through the process of reselecting them in the Filter dialog. Confirming comment 16
(In reply to Lionel Elie Mamane from comment #12) > Well, let's say at least it is not a regression because it was always like > that, as far as I can remember. Is there consensus on this not being a regression? (if so, we should remove the 'regression' keyword)
(In reply to Robinson Tryon (qubit) from comment #21) > (In reply to Lionel Elie Mamane from comment #12) > > Well, let's say at least it is not a regression because it was always like > > that, as far as I can remember. > > Is there consensus on this not being a regression? (if so, we should remove > the 'regression' keyword) There seems to be a mix of different sub-issues here. The original issue mentioned in comment 0 IS a regression and IS fixed. The issue mentioned in comment 11, is AFAIK not a regression. The issue mentioned in comments 14 to 18 and 20 is UNCONFIRMED (only Alex has mentioned it). I recommend the other issues are forked into DIFFERENT bugs and this bug be CLOSED/FIXED again.
(In reply to Lionel Elie Mamane from comment #22) > There seems to be a mix of different sub-issues here. > > The original issue mentioned in comment 0 IS a regression and IS fixed. > > The issue mentioned in comment 11, is AFAIK not a regression. > > The issue mentioned in comments 14 to 18 and 20 is UNCONFIRMED (only Alex > has mentioned it). > > I recommend the other issues are forked into DIFFERENT bugs and this bug be > CLOSED/FIXED again. Removing 'regression' keyword. Marking Summary so I don't spend time on this bug again.
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Following Lionel's piece of advice on comment 22, let's put this one to FIXED since the original pb has been fixed. Don't hesitate to create new bugtrackers if the 2 other bugs can still be reproduced with a recent LO version (6.0.6 or brand new 6.1.1).