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
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?
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) 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
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: 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)
(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.
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.
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 !
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
(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
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.
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.
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.
*** Bug 73198 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (PossibleRegression) [NinjaEdit]