Created attachment 90748 [details]
a database created with 4.2 Beta2 that shows the problem
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
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.
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).
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
Last worked in: 188.8.131.52 release
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 184.108.40.206beta2 and reopen with, for example, 220.127.116.11. 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 18.104.22.168beta2.
It doesn't appear in 22.214.171.124 from 2013-11-22_23:47:31.
It also doesn't appear in LO 126.96.36.199beta1.
Lionel, might you have a look at this?
Could someone please try if this is fixed by the fix to bug 72463? Thanks in advance.
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?
(In reply to comment #3)
> 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 188.8.131.52beta2 the content of the tablecontrol wouldn't be changed - shows for every row of the mainform the same content.
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.
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?
I made another test with last file:
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.
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)
(In reply to comment #7)
> I made another test with last file:
> 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.
> 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 184.108.40.206beta2. 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.
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.
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 !
(In reply to comment #2)
> Could someone please try if this is fixed by the fix to bug 72463? Thanks in
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: 220.127.116.11.beta2+
Build ID: d663228bd348c844f38914c9e2167ef01fadf3b3
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-14_23:15:05
(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: 18.104.22.168.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 (22.214.171.124.beta2+).
I still reproduce on windows 7/64 with Version: 126.96.36.199.alpha0+
Build ID: f279acd3678d014d9d5dafe41971e0da4dec7b6c
TinderBox: Win-x86@47-TDF, Branch:master, Time: 2013-12-13_23:25:16
I can now reproduce the bug in Version: 188.8.131.52.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 184.108.40.206.alpha from 2013-11-22.
I think there must be different reasons for this bug, because the one will work, the other not.
Another test: The oldest LO220.127.116.11-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.
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":
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:
Affected users are encouraged to test the fix and report feedback.
*** Bug 73198 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (PossibleRegression)