Issue 64898

Summary: show referenced record in subform for new record in main form
Product: Base Reporter: Regina Henschel <rb.henschel>
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues, mh.hh
Version: 680m164   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
databae example none

Description Regina Henschel 2006-04-29 00:31:57 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.
Comment 1 Regina Henschel 2006-04-29 00:32:55 UTC
Created attachment 36143 [details]
databae example
Comment 2 Frank Schönheit 2006-05-05 09:03:23 UTC
grabbing, targeting
Comment 3 Frank Schönheit 2006-05-05 09:03:54 UTC
accepting
Comment 4 Frank Schönheit 2006-06-16 12:41:43 UTC
targeting to 2.x, which is the depot for issues ot be fixed for one of the next
releases
Comment 5 Frank Schönheit 2006-07-26 13:35:32 UTC
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 ...
Comment 6 Frank Schönheit 2007-02-22 09:45:36 UTC
pushing out to Later, sorry, don't have a convincing idea at the moment how to
do this.
Comment 7 mhatheoo 2008-01-16 22:28:09 UTC
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
Comment 8 mhatheoo 2008-04-02 13:54:16 UTC
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


Comment 9 mhatheoo 2008-04-08 20:26:21 UTC
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
Comment 10 Frank Schönheit 2008-04-08 20:37:47 UTC
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
Comment 11 Marcus 2017-05-20 10:45:36 UTC
Reset the assignee to the default "issues@openoffice.apache.org".