Apache OpenOffice (AOO) Bugzilla – Issue 64898
show referenced record in subform for new record in main form
Last modified: 2017-05-20 10:45:36 UTC
I've got a n:m-relationship, which is split into the tables: Kurse: KursID (primary) | Thema | Dozent Teilnehmer: KdID (primary) | Name | Geburtsdatum | Vorname | weiblich wer_was: wer (compound primary; reference to Teilnehmer.KdID) | was (compound primary; reference to Kurse.KursID) I create a form “Belegung mit Kontrolle†(see attached document) for to insert new records into the table wer_was. It contains a listbox for entering a value into wer_was.wer, which shows Teilnehmer.KdID. For checking whether I choose the right KdID, my form has a subform on Teilnehmer which shows the referenced record. If you open the form and browse the records with the form navigation, you see the referenced records in the fields of the subform. But if you will enter a new record in wer_was and have chosen a value for wer_was.wer, then these field of the subform are empty. RFE: If the field in the main form has a valid value, then the subform should show the referenced record although the value has not been transmitted to the database yet.
Created attachment 36143 [details] databae example
grabbing, targeting
accepting
targeting to 2.x, which is the depot for issues ot be fixed for one of the next releases
after looking deeper into this, I tend to disagree partly. First, it's not really about displaying "the" referenced sub record, but about re-loading the complete sub form. However, reloading the sub form every time the master form's control value changes might be too expensive - do we really want all this database traffic every time I select a new entry in the master form? On the other hand, currently the content of the list box is committed to the record (but not yet to the database) as soon as it loses the focus. That's currently the only event we can monitor: a change in the value of the record field, *not* a change in the control which is bound to this field. Effectively, this means that you could change the entry in the list box, but the sub form would not yet reload. Only when you leave the list box, the sub form is reloaded. That might be surprising to the user ... but unfortunately, implementing a reload on a change in the control is pretty difficult with the current infrastructure. Not to mention that it would need to be defined what happens if the master form had two controls both bound to the same record field ... So, this leaves us with: We could implement a behavior where the sub form is refreshed as soon as you leave the control in the master form. Not sure if this is expectation-conformant for the user, and thus desirable. Alternatively (or additionally?), the following seems to be missing: When I update an existing master record to the database, then the sub form is not refreshed, too. That is, if I change the master field which defines the sub form content (say, I select a different "wer" in the master form), then the respective sub form still displays the old content - which is somewhat inconsistent. At the latest when the master form is really committed to the database, the sub form should respect the new master record content. So, the options are - implement "on-master-control-change" (any content change in the master form's control) update of the sub form (pretty difficult, and currently underspecified) - implement "on-master-control-commit" (focus lost) update of the sub form - implement "on-master-record-commit" (focus the sub form, or press "Save Record" in the toolbar) update of the sub form - none of those :) Not sure at the moment how to best procede here ...
pushing out to Later, sorry, don't have a convincing idea at the moment how to do this.
Hello Regina this is not an issue, this is the wrong concept You need to splitt up the n:m-middle-man-table to n:1 and 1:m subforms. ( however, it is an issue anywhy, as you can not seriously deal-with/ jump-to the needed 1:n -sub-forms to enter new data, as neither working lookup nor a jump-to nor a commit is available, but thats another story) Martin
At Frank Am I right, behavior did not change in 2.4.0 ? in your mail dated 26.07.2006 you mentioned, that "traffic" can be a problem. I would suggest you should not treat this as a point, for the price of loosing - or not finding - a working DBMS-concept. Your summary is correct, any change of one of the three files needs a re-query, and as it is too complicate to deal with file-status-controlling flags (which may come later) it would be a good idea to have a re-query on any automatic or manual initiated view to the records Martin
at Frank I just came along a couple of issues you delt with the past few days, all related to main- and sub-form-issues (relational-issues) and the effect it has on listboxes. You found a pracmatical solution for that, but - look at my mail right above - at actual it is not how SQL should behave. So I have a question: I guess you do not want to have my comment on every issue with subforms/refresh of relations. So where would you like to collect these? Would you mind to open a new issue, just dealing with build-in "non-SQL-conform" behavior just for performance-reasons? rgds Martin
Sorry, I lost your previous comment from my radar ... actually, I didn't completely get it, anyway :) I suggest carrying the discussion to users@dba.openoffice.org: http://wiki.services.openoffice.org/wiki/Base_Mailing_List
Reset the assignee to the default "issues@openoffice.apache.org".