Bug 72696 - Other: Form ignores primary-foreign key pair relationship for a subform
Summary: Other: Form ignores primary-foreign key pair relationship for a subform
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.2.0.0.beta2
Hardware: Other Linux (All)
: high major
Assignee: Lionel Elie Mamane
URL:
Whiteboard: BSA target:4.3.0
Keywords: possibleRegression
: 73198 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-13 21:52 UTC by Dan Lewis
Modified: 2015-12-15 22:09 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
a database created with 4.2 Beta2 that shows the problem (16.99 KB, application/vnd.oasis.opendocument.database)
2013-12-13 21:52 UTC, Dan Lewis
Details
Form with subform. Content in tablecontrol must change when row in mainform changes. (17.15 KB, application/vnd.sun.xml.base)
2013-12-14 14:32 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Lewis 2013-12-13 21:52:15 UTC
Created attachment 90748 [details]
a database created with 4.2 Beta2 that shows the problem

Problem description: 
Table A has a foreign key linked to the primary key of Table B. Table B has a foreign key linked to the primary key of Table C. After a form is created and data is entered, the form is opened. When records are changed in the main form, there is no change in the data in the sub form.

Steps to reproduce:
1. Create Table A with a primary key, some fields, and a foreign key.
2. Create Table B with a primary key, some fields, and a foreign key.
3. Create Table C with a primary key.
4. Using Tools > Relationships, click the New Relations icon. Place     
   Table A and its foreign key on the left side of the dialog and Table 
   B and its primary key on the right side.
5. Select No Action as the option for both the Update and Delete 
   options. Click OK to close the option.
6. Follow steps 4 and 5 to define the relationship between Table B and 
   Table C.
7. Save the relationship, and save the database.
8. Create a form with a main form (Table B) and sub form (Table A).
9. If using Design View to create the form, create the second sub form 
   containing Table C. Use the Form icon to define the two 
   relationships. Save the form, and save the database.
10. Enter data into the form: into the main form and both sub forms so 
    that you have three or four records.
11. Use the form navigation toolbar to change the record that is visible.

Current behavior
    When the record is changed in the main form (Table B), records are not changed in the sub form (Table A). Changing the active record in the sub form (Table B) does not change the records visible in the other sub form (Table C).

Expected behavior:
    When a record is changed in the main form (Table B), the visible records of the sub form (Table A) change to the ones that relate to the new record of the main form.
              
Operating System: Debian
Version: 4.2.0.0.beta2
Last worked in: 4.1.3.2 release
Comment 1 Robert Großkopf 2013-12-14 09:18:06 UTC
I can confirm this behavior.
Open the attached database. 
Open The form for editing. 
Change the subform-properties to "Add Data only" → "No". 
Safe the form.
Open the form for editing data.
Change the row in the mainform.
The subform doesn't change the shown data.

Close LO 4.2.0.0beta2 and reopen with, for example, 4.1.4.2. The form would show different values in the subform, when you change the row of the mainform.

The contact between subform and mainform seems to be broken.

This bug appears in LO 4.2.0.0beta2.
It doesn't appear in 4.3.0.0 from 2013-11-22_23:47:31.
It also doesn't appear in LO 2.2.0.0beta1.

Lionel, might you have a look at this?
Comment 2 Lionel Elie Mamane 2013-12-14 09:24:58 UTC
Could someone please try if this is fixed by the fix to bug 72463? Thanks in advance.
Comment 3 Julien Nabet 2013-12-14 12:28:12 UTC
I don't know enough Base and so can't distinguish main form of subform.

I just some 5 fields + a form with rows. Is this last one the main or the subform but anyway, where's the other form?
Comment 4 Robert Großkopf 2013-12-14 14:28:50 UTC
(In reply to comment #3)
Hi Julien,
 
> I just some 5 fields + a form with rows. Is this last one the main or the
> subform but anyway, where's the other form?

There is a table-control in the form - a form with rows, as you call it. This is the main-form. The content of the tablecontrol changes, when you change the row of the mainform.
The following will only work when you have changed the form as I described in Comment1.
Put the cursor in "Transaction No.". At the bottom of the form you would see "Row 1 from 4". In the tablecontrol you see 5 rows. Now go to next row in the navigationbar, which shows "Row 1 from 4". The content from the whole form has to be changed. You could see 2 rows in the tablecontrol.
When you do this with LO 4.1.0.0beta2 the content of the tablecontrol wouldn't be changed - shows for every row of the mainform the same content.

Regards

Robert
Comment 5 Robert Großkopf 2013-12-14 14:32:44 UTC
Created attachment 90771 [details]
Form with subform. Content in tablecontrol must change when row in mainform changes.

Have changed the attachment. So you only have to start the form and see the difference, when moving from one row to another in the mainform.
Comment 6 Julien Nabet 2013-12-14 14:45:13 UTC
Here what I did:
- downloaded the last file and opened the last file
- open the form
- move the cursor (up/down) in the rows
no changes in the upper fields

To compare, I did too:
- opened the previous file
- open the form (so did not change the properties of the form)
- no rows here just the upper fields are filled

Is it ok?
Comment 7 Julien Nabet 2013-12-14 14:53:40 UTC
I made another test with last file:
1)
first when I open the form, I got:
Pay  stub/Sears/"15/01/2010" formatted/$1,533.65

and 5 rows

It's record 1 from 4.

2)
Then click next record (so 2 from 4)
the content of upper fields change but still the 5 rows at the bottom

Idem if click next record (so 3 from 4 and 4 from 4)

at 5, all rows disappear

Go previous record -> 2 rows (instead of 5)
Comment 8 Robert Großkopf 2013-12-14 15:13:01 UTC
(In reply to comment #7)
> I made another test with last file:
> 1)
> first when I open the form, I got:
> Pay  stub/Sears/"15/01/2010" formatted/$1,533.65
> 
> and 5 rows
> 
> It's record 1 from 4.
> 
> 2)
> Then click next record (so 2 from 4)
> the content of upper fields change but still the 5 rows at the bottom
> 
> Idem if click next record (so 3 from 4 and 4 from 4)
> 
> at 5, all rows disappear
> 
> Go previous record -> 2 rows (instead of 5)

That is the buggy behavior of LO 4.2.0.0beta2. When you start the same form in beta1 or all other versions you get different rows at the bottom, when you change the number for the record above. As you see it first connects 5 rows to the data of the mainform. When you have reached "New row" and go back it connects 2 (other) rows.
Don't know where to get a build with the patch for bug72463. Could be it is the same reason, because it first appears with the same build and has something to do with the refresh of tables.
Comment 9 Julien Nabet 2013-12-14 15:19:13 UTC
RObert:
Except if I forgot to launch the build after having runned ./g pull -r, I had this commit in my local repo.
Anyway, I'm updating right now then will build.
Comment 10 Julien Nabet 2013-12-14 22:03:18 UTC
Just for information, when clicking button next record to go to 5th, I got this on console:
warn:legacy.osl:30464:1:forms/source/component/CheckBox.cxx:288: OCheckBoxModel::commitControlValueToDbColumn: could not commit !
Comment 11 pierre-yves samyn 2013-12-15 07:50:14 UTC
Hi Lionel

(In reply to comment #2)
> Could someone please try if this is fixed by the fix to bug 72463? Thanks in
> advance.

I do not know if the patch has been included in this version or not
but I still reproduce on windows 7/64 with Version: 4.2.0.0.beta2+
Build ID: d663228bd348c844f38914c9e2167ef01fadf3b3
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-14_23:15:05

Regards
Pierre-Yves
Comment 12 pierre-yves samyn 2013-12-15 10:55:14 UTC
(In reply to comment #11)
> (In reply to comment #2)
> > Could someone please try if this is fixed by the fix to bug 72463? Thanks in
> > advance.
> 
> but I still reproduce on windows 7/64 with Version: 4.2.0.0.beta2+
> Build ID: d663228bd348c844f38914c9e2167ef01fadf3b3
> TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-14_23:15:05

Sorry my mistake: This test was unnecessary (4.2.0.0.beta2+).


I still reproduce on windows 7/64 with Version: 4.3.0.0.alpha0+
Build ID: f279acd3678d014d9d5dafe41971e0da4dec7b6c
TinderBox: Win-x86@47-TDF, Branch:master, Time: 2013-12-13_23:25:16

Regards
Pierre-Yves
Comment 13 Robert Großkopf 2013-12-15 18:56:26 UTC
I can now reproduce the bug in Version: 4.3.0.0.alpha0+
Build ID: b1ac01de06262bda39be7f970fbceeda9b267fe4
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2013-12-15_08:27:48 
The bug72463 (refreshing table doesn't work) does not exist in this version.

Remember: I couldn't confirm this bug with LO 4.3.0.0.alpha from 2013-11-22.


I think there must be different reasons for this bug, because the one will work, the other not.
Comment 14 Robert Großkopf 2013-12-15 19:11:50 UTC
Another test: The oldest LO4.3.0.0-version I could get from the daily builds is from 2013-12-04. In this version both bugs appear: bug72463 (which is fixed in the version from 2013-12-15) and this bug. So this bug must be introduced between 2013-11-22 and 2013-12-04.
Comment 15 Commit Notification 2013-12-16 03:18:28 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2042665c6d936124f097146c285773774304f4bd

fdo#72696 set parameters when they have changed



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.
Comment 16 Robert Großkopf 2014-01-01 18:57:59 UTC
*** Bug 73198 has been marked as a duplicate of this bug. ***
Comment 17 Robinson Tryon (qubit) 2015-12-15 22:09:49 UTC
Migrating Whiteboard tags to Keywords: (PossibleRegression)
[NinjaEdit]