Bug 45257 - EDITING Relation designer does not pick up all existing relationships
Summary: EDITING Relation designer does not pick up all existing relationships
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.5.0 RC2
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 88033 (view as bug list)
Depends on:
Blocks: Database-Tables
  Show dependency treegraph
 
Reported: 2012-01-25 23:54 UTC by Drew Jensen
Modified: 2022-10-07 03:38 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2012-01-25 23:54:30 UTC
Tested w/ Ubuntu 11.04, Lbo 3.5 RC2, Postgresql 8.4

Open an ODB connected to a postgresql database with muliple relationship constraints.

Open the relation design window.

Not all relationships will be displayed - in testing this was true 100% of the time the first time that window is opened. But if you do anything to that makes LibO think the window contents should be saved (even if you just trick it) and do so, then close the window and reopen it, most of the time (sorry it is not all the time) it then picks up the other relationships.

This seems to be limited to the relation design window as the Query designer and/or wizard and form wizard pick up all of the relationships right fro the start.
Comment 1 sasha.libreoffice 2012-05-11 03:02:01 UTC
Thanks for bugreport
Please, attach small database with which this bug reproducible. Or add link where it can be downloaded. May be test databases for Postgresql exists, tell if so.

Also attach odb file that demonstrates this problem.
Comment 2 Alex Thurgood 2012-07-23 08:05:15 UTC
Drew,

I can confirm similar behaviour with regard to the native mysql connector extension and a mysql server.

The problem appears to indeed lie with the Relationship designer tool/dialog.

In my own case :

- dragging and dropping to create a relationship between two tables appears to work, but only once between any two tables - in reality, the relationship is not created, the graphical UI representation always default to the first entry in the first table's field list, and if you click on the link to edit the relationship displays only one half, as it turns out the second table to which the link was made without referencing any field from the first table !!!

- trying to manually create a relationship by clicking on the Define button allows one to choose the fields from the tables to be linked, but when validated, fails to do this correctly, i.e. we get a repeat of the scenario above, whereby only the first field of one table appears, and this link only includes one field from one table, and not even the one that was defined by the user !!!

The whole relationship design tool/dialog seems broken, at least for external db's, I haven't tried with hsqldb internal.



Alex
Comment 3 Alex Thurgood 2012-07-23 10:48:10 UTC
Confirming as reproducible on LibreOffice 3.5.5.3 Mac OSX 10.7.4.

Test database : XTuple (http://www.xtuple.com/free-demo-of-xtuple-erp)

Using the built-in connector, when I call Tools > Relationships, the window opens but does not bring up any of the predefined relationships in the database. I get a Table list window, asking me to add the tables to define the relationships I want.


Compare the above behaviour to the same database, using a postgres JDBC connector:
- the relationships are displayed, in fact, so many of them that they overlap each other within the window (but that is not a new problem as such, it has always been that way, independent of the underlying database).

Conclusion : it works in with JDBC and not with sdbc-postgres.


Alex
Comment 4 Toni Ballesta 2013-08-18 09:06:07 UTC
Confirmed on NEWER 4.1.0.4. The problem is the same. Sometimes the relationships are correctly, sometimes not. I've over 30 tables with Postgresql. Opening, closing, reopening... and some relationships appear and disappear. No changes from the psql console: the CONSTRAINT values is not altered.
Comment 5 Alex Thurgood 2015-01-03 17:39:04 UTC Comment hidden (no-value)
Comment 6 Alex Thurgood 2015-02-04 17:15:24 UTC
Changing title because the problem is independent of db engine
Comment 7 Alex Thurgood 2015-02-04 17:16:17 UTC
*** Bug 88033 has been marked as a duplicate of this bug. ***
Comment 8 Julien Nabet 2015-02-08 22:22:01 UTC
Alex/Drew: I put it at NEEDINFO, waiting for your feedback about this tracker.
Comment 9 Alex Thurgood 2015-02-09 06:04:51 UTC
(In reply to Julien Nabet from comment #8)
> Alex/Drew: I put it at NEEDINFO, waiting for your feedback about this
> tracker.

What information do you need ?

The duplicate report bug 88033 contains a sample document and screenshots explaining and showing the problem.
Comment 10 Alex Thurgood 2015-02-09 06:07:14 UTC
(In reply to Alex Thurgood from comment #9)
> (In reply to Julien Nabet from comment #8)
> > Alex/Drew: I put it at NEEDINFO, waiting for your feedback about this
> > tracker.
> 
> What information do you need ?
> 
> The duplicate report bug 88033 contains a sample document and screenshots
> explaining and showing the problem.

In bug 88033, the bug was reported against LO 4352, I confirmed on master Version: 4.5.0.0.alpha0+
Build ID: 6143a7eeabea394133c54e97e3690bdf40b98247
Locale: fr_

on OSX 10.10.2
Comment 11 Julien Nabet 2015-02-09 06:34:08 UTC
Alex: Sorry, had missed information from tdf#88033, I'll take a look, thank you! :-)
Comment 12 Julien Nabet 2015-02-09 22:20:32 UTC
Ok, I reproduced the bug.

In fact, it seems that only 1 relation is possible between 2 tables.
Indeed, if I remove link between "tbl_product" and "tbl_bug" then add another one, it's ok.

I noticed too that when trying to create second relation, cardinality doesn't appear. Perhaps both behaviors are linked.
Comment 13 Julien Nabet 2015-02-10 21:25:44 UTC
I'm lost by the number of parts involved:
dbaccess/source/ui/control/RelationControl.cxx
svtools/source/brwbox/editbrowsebox.cxx
svtools/source/brwbox/brwbox1.cxx
...
example of bt:

#0  dbaui::ORelationControl::getColumnIdent (this=0x2fb5c90, _nColId=65535) at /home/julien/compile-libreoffice/libreoffice/dbaccess/source/ui/control/RelationControl.cxx:274
#1  0x00002aaad025c15d in dbaui::ORelationControl::InitController (this=0x2fb5c90, nRow=0, nColumnId=65535)
    at /home/julien/compile-libreoffice/libreoffice/dbaccess/source/ui/control/RelationControl.cxx:305
#2  0x00002aaaafbd8b73 in svt::EditBrowseBox::ActivateCell (this=0x2fb5c90, nRow=0, nCol=65535, bCellFocus=true)
    at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/editbrowsebox.cxx:1027
#3  0x00002aaaafbda5c1 in svt::EditBrowseBox::ActivateCell (this=0x2fb5c90) at /home/julien/compile-libreoffice/libreoffice/include/svtools/editbrowsebox.hxx:571
#4  0x00002aaaafbd888d in svt::EditBrowseBox::CursorMoved (this=0x2fb5c90) at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/editbrowsebox.cxx:987
#5  0x00002aaaafbac049 in BrowseBox::GoToRow (this=0x2fb5c90, nRow=0, bRowColMove=false, bKeepSelection=false)
    at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/brwbox1.cxx:1544
#6  0x00002aaaafbaaa01 in BrowseBox::RowInserted (this=0x2fb5c90, nRow=0, nNumRows=2, bDoPaint=true, bKeepSelection=false)
    at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/brwbox1.cxx:1243
#7  0x00002aaad025b694 in dbaui::ORelationControl::lateInit (this=0x2fb5c90) at /home/julien/compile-libreoffice/libreoffice/dbaccess/source/ui/control/RelationControl.cxx:187
#8  0x00002aaad025e3cc in dbaui::OTableListBoxControl::lateInit (this=0x2fadd40)
    at /home/julien/compile-libreoffice/libreoffice/dbaccess/source/ui/control/RelationControl.cxx:673

Value of nCol seems strange but I can't succeed in understanding the whole mechanism, too messy!
Comment 14 Lionel Elie Mamane 2015-02-11 05:52:21 UTC
(In reply to Julien Nabet from comment #13)
> Value of nCol seems strange

This looks like the special value "unknown/invalid column":

include/svx/gridctrl.hxx:#define GRID_COLUMN_NOT_FOUND   SAL_MAX_UINT16
Comment 15 QA Administrators 2016-02-21 08:36:45 UTC Comment hidden (obsolete)
Comment 16 James B. Byrne 2016-03-01 13:58:25 UTC
LO-5.0.3.2
CentOS-6.7

Bug remains in this version.  When attempting to add relationships from multiple fields in one table to the primary key of another relationships added subsequent to the first generate an error and cause a relationship editing window to appear.  If the multiple relationships (T2.field1 -> T1.id, T2,field2 -> T1.id, T2.field3 -> T1.id) are entered manually in the relationship editing window then LO crashes and the recovery shows no trace of the previously attempted work.
Comment 17 QA Administrators 2017-03-06 15:37:00 UTC Comment hidden (obsolete)
Comment 18 Terrence Enger 2017-04-15 22:36:50 UTC
I still see the bug with debian stretch running daily Linux dbgutil
bibisect repository version 2017-04-15 with an embedded Firebird
database.

I have the example .odb and STR, but I think they do not add much to
what is already here.
Comment 19 Terrence Enger 2017-04-15 22:42:48 UTC
*** Bug 101230 has been marked as a duplicate of this bug. ***
Comment 20 Julien Nabet 2017-07-29 22:18:30 UTC
(In reply to Terrence Enger from comment #18)
> I still see the bug with debian stretch running daily Linux dbgutil
> bibisect repository version 2017-04-15 with an embedded Firebird
> database.
> 
> I have the example .odb and STR, but I think they do not add much to
> what is already here.

About Firebird, it's been fixed with https://cgit.freedesktop.org/libreoffice/core/commit/?id=d499cb3bd585e9fcc21bc586cad3d2ad2487a451 for tdf#107196

For other databases any better with recent LO version? (last stable one is 5.3.4)
Comment 21 QA Administrators 2018-07-30 02:36:38 UTC Comment hidden (obsolete)
Comment 22 QA Administrators 2020-10-06 03:44:39 UTC Comment hidden (obsolete)
Comment 23 QA Administrators 2022-10-07 03:38:17 UTC
Dear Drew Jensen,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug