Created attachment 136586 [details]
On the 22.214.171.124, it is possible to create a relationship between a primary column and an ordinary column, however, in the 5.4.1, it requires that the both column must be set to primary.
@perle_gut : please explain in detailed steps what it is your are attempting to do and provide a sample ODB file with instructions that we could try to follow to reproduce.
What kind of DB (embedded hsqldb, firebird, or external db) ?
How are you setting up the relationship (GUI, DDL/SQL, or backend instructions to db engine) ?
Setting to NEEDINFO.
Created attachment 136610 [details]
sample of the db
Here is a sample of the HSQLDB. I was able to create the existing relationship using the stable release... If you are to recreate the entire db on a fresh release, then you will encounter the said error.
Have tested this one with OpenSUSE 42.2 64bit rpm Linux and
LO Version: 126.96.36.199
CPU-Threads: 4; Betriebssystem:Linux 4.4; UI-Render: Standard; VCL: kde4;
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Deleted the relationship between "PropertyType"."PropertyType" and "PropertyDetails"."PropertyType".
Then saved and closed Base and LO.
Reopened and set relationship.
When drawing from "PropertyDetails"."PropertyType" to "PropertyType"."PropertyType" the fields were connected well. You could save and reopen and the relationship is there.
Drawing the other way there doesn't appear 'n' and '1'. You are asked for the properties. If you only confirm this nothing happens. After saving and reopening the relationship has been gone.
Same buggy behavior with LO 188.8.131.52, also with all other versions down to 184.108.40.206. Haven't installed any version before, but it seems to be a very old bug. If you change the properties in the dialog for relationship to any action when deleting or updating something the relationship will be created well in every version of LO. Seems to be a bug in the dialog.
Could be this isn't the bug the reporter has detected - but this one I could confirm.
I submitted this patch for review:
It fixes the precise buggy behaviour described by Robert but, as him, I don't know if it corresponds to the bug report.
I added traces to compare the 2 ways of adding relationship:
1) From non primary->primary (which works)
ORelationTableView::AddConnection call addConnection
2) From primary->non primary (which doesn't work)
@@ -61,8 +61,7 @@ ORelationTableConnectionData::ORelationTableConnectionData( const TTableWindowDa
m_aConnName = rConnName;
- if ( !m_aConnName.isEmpty() )
So in this last case:
no call to Update -> m_vConnLineData has a size of 0 -> checkPrimaryKey returns always false -> SetCardinality lets m_nCardinality to Cardinality::Undefined
Version: 220.127.116.11 (x64)
Build ID: da790616461e15a10c95a80eb8ef8ee7b726c114
CPU threads: 4; OS: Windows 6.19; UI render: default;
Locale: en-US (en_US); Calc: CL
As of the latest version, I still was not able to saved the relationship for the following:
ContractDetails.BargainPurchaseOptionType = BargainPurchaseOption.BargainPurchaseOption
*also for the BargainRenewalOption
and I have tried to manually create the relationship (from insert > relationship) and got the following error
SQL Status: S0011
Error code: -170
Primary or unique constraint required on main table: "BargainRenewalOption" in statement [ALTER TABLE "ContractDetails" ADD FOREIGN KEY ("BargainRenewalOption") REFERENCES "BargainRenewalOption" ("BargainRenewalOption")]
perie: why did you set this to FIXED ?
(In reply to perie_gut from comment #6)
> As of the latest version, I still was not able to saved the relationship for
> the following:
> ContractDetails.BargainPurchaseOptionType =
> *also for the BargainRenewalOption
> and I have tried to manually create the relationship (from insert >
> relationship) and got the following error
> SQL Status: S0011
> Error code: -170
> Primary or unique constraint required on main table: "BargainRenewalOption"
> in statement [ALTER TABLE "ContractDetails" ADD FOREIGN KEY
> ("BargainRenewalOption") REFERENCES "BargainRenewalOption"
Error appears, because "BargainRenewalOption" isn't unique. There are two primary-keys in the table. So how should the database be able to know which of the different rows of "BargainRenewalOption" will be the right?
Julien, because of the stupid comment that I have posted earlier. Nevertheless, the issues identified before seams okay already when I tried with 5.4.3 version. I'll just set the ticket open.
Let's revert to the previous state before the FIXED put by mistake.
Created attachment 141394 [details]
trying to create a relationship to a table with 2 primary keys
Still cannot create a relationship to a table with 2 primary keys
Version: 18.104.22.168 (x64)
Build ID: 8f48d515416608e3a835360314dac7e47fd0b821
CPU threads: 4; OS: Windows 10.0; UI render: default;
Locale: en-PH (en_PH); Calc: group
log : 8f48d515416608e3a835360314dac7e47fd0b821
(In reply to perie_gut from comment #11)
> Created attachment 141394 [details]
> trying to create a relationship to a table with 2 primary keys
> Still cannot create a relationship to a table with 2 primary keys
Seems you are trying to create relationships between tables, which contain both more than one primary-key. I have tried this through direct SQL:
1: Primary or unique constraint required on main table: "journal_lines" in statement [ALTER TABLE "accountcode" ADD FOREIGN KEY ("accountcode") REFERENCES "journal_lines" ("accountcode")]
2: Primary or unique constraint required on main table: "accountcode" in statement [ALTER TABLE "journal_lines" ADD FOREIGN KEY ("accountcode") REFERENCES "accountcode" ("accountcode")]
You need a unique-field if you want to create a relationship. Three of of the tables doesn't have a unique-field. The have more than one primary key. HSQLDB doesn't support this.
The only bug here is: The GUI doesn't recognize this relation isn't be allowed. It paints a connection which doesn't show 1:1 or 1:n but this connection couldn't be saved.
Which tables did you try to connect with which relation?
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!