Solved Theoretical question

[so10070]

It is possible to make a link between child and master through VBA, like this

        .RecordSource = sqlOffertesWijzigenBasis
        .subfrmOfferteProductenWijzigen.Form.RecordSource = sqlProductOffertesWijzigen
        .subfrmOfferteProductenWijzigen.LinkChildFields = "OFID"
        .subfrmOfferteProductenWijzigen.LinkMasterFields = "OFID"

It is also possible to make the link between child and master through the properties. But even every form (child and master) has its own recordsource defined in the "Form_Load" it is obliged to fill in explicitly the recordsource of the master in the properties.

Why?

 

[Gasman]

Flexibility?

it is obliged to fill in explicitly the recordsource of the master in the properties.

Are you sure about that?

 

[The_Doc_Man]

I am not sure I understand your question.

Your displayed code accurately shows how you would dynamically link parent and child forms and the .Recordsource for the parent and for the child. You are correct that you could define these properties statically in design view using the properties grid. In fact, that is the preferred way.

I don't understand your reference to the Form_Load event. Unless the latest version of Access 365 has a requirement that I haven't seen before, there is absolutely no obligation to load ANY of those properties in code for ANY event. They should all work perfectly by statically defining them from design view. You are not obliged to make any such definitions - UNLESS the creator of the database is doing something extremely unusual.

 

[CJ_London]

If you have already defined the relationship the link properties are populated automatically - but you can delete or use different fields.

you can also use two or more fields, separated by a comma

e.g. you might have a main form based on customers and a subform based on invoices either the link based on customer Id. But you could add an unbound control on the main form to specify say invoice type (e.g. invoice/credit) and add this control name to the link master property (e.g. customerpk, cboinvtype) and the link child property Customerfk, invtype)

 

[XPS35]

Crossposted here https://www.helpmij.nl/forum/showthread.php/965826-Theoretische-vraag#post6338680

 

[so10070]

Thanks all for the very useful information. As I understand it, one have to choose what method he or she will use.

 

[gemma-the-husky]

I don't think you would normally do this at run time, unless you have some dynamic process where you changed the subform sourceobject programmatically. Generally it's easier to assert the master-subform relationship in the form design

 

[GPGeorge]

I am not sure I understand your question.

Your displayed code accurately shows how you would dynamically link parent and child forms and the .Recordsource for the parent and for the child. You are correct that you could define these properties statically in design view using the properties grid. In fact, that is the preferred way.

I don't understand your reference to the Form_Load event. Unless the latest version of Access 365 has a requirement that I haven't seen before, there is absolutely no obligation to load ANY of those properties in code for ANY event. They should all work perfectly by statically defining them from design view. You are not obliged to make any such definitions - UNLESS the creator of the database is doing something extremely unusual.

In one very obscure situation--the details of which are lost in history--I had to resort to setting the Master and Child linking fields in a main form subform design during runtime. What I do remember is that the predecessor who'd created the original application had done something that made it hard to accomplish what I needed to so--refresh data after some update process ran--which made this the path of least resistance short of a whole new set of forms. I wish I could remember the specific problem that led to this. All I recall is that it was the first and last time I did it, or wanted to do it.

 

[The_Doc_Man]

Thanks all for the very useful information. As I understand it, one have to choose what method he or she will use.

True enough - but unless you are doing something to extensively alter a LOT of things at run-time, that choice is HEAVILY weighted to defining all of those factors during design time so that your DB comes up with them already loaded so that you don't have to do anything else. They are just there, in-place and ready to go. Dynamic redefinition at run-time also incurs a slight performance penalty for each using that method each time the form is loaded. If the form is simple enough, the hesitation won't be obvious, but changing the .RecordSource DOES require a second .Requery on any form after the one implied by a Form_Load event.