Display many to many relationship in continuous form - ms-access

Question

I can't figure out how to display a column that has many value for the same record in a continuous form
I got 3 tables
SalesCall
SalesCallId | etc..
Mill
MillId | name...
SalesCallMills <------ Junction table
Id | SalesCallId | MillID
the basic design for a many to many relationship.
When it's a simple form, I'm used to do a list and change the control source for the current ID with a SQL query.
What's the common practice to display this in a continuous form?
This was the form before when only 1 mill was possible.
I thought I could concat the mills, but it will be hard to read and it will be way to long.
So I thought about a list but I don't think it's possible to change the control source for each record.
Also, good to mention that this is read-only. It's not for adding or editing. The form to enter data is already made. And I think that one mill per record is not an option cause it would really confuse the user.
What's the proper way to display a multi value column with my database design?

Answer 1

This is a form with correlated subforms.
The two forms are synchronized via the link child and master fields:
Link Master Fields: Forms!Form7![SalesCall Subform].Form.SaleID
Link Child Fields: SalesCallId
And a little code in the Current Event of subform #1
Private Sub Form_Current()
Me.Parent.[SalesCallMills subform].Form.Requery
End Sub
Selecting a line in subform #1 displays the relevant detail lines in subform #2.
It should not be difficult to add suitable information on such things as mill name to the general outline.

Answer 2

The Junction Table will be the mainstay of your select, and you will hang the other tables from it.
You can use the Query Editor to view it visually, but the SQL statement would look like:
SELECT *
FROM (SalesCallMills
INNER JOIN SalesCall
ON SalesCallMills.ID=SalesCall.SalesCallID)
INNER JOIN Mill
ON SalesCallMills.ID=Mill.MillID;
(Access likes brackets around multi-table joins, so while they are not necessary for a pure SQL statement, Access will not work properly without them)
To view all the Mills against each SalesCall in a single line, you will have to leave the simple query behind, and write your own (vba) function
http://allenbrowne.com/func-concat.html has an example, and the code that will allow you to set the Mills field on your current form to something like =ConcatRelated("name", "Mill", "MillID= " & SalesCallMills.ID)

Answer 3

You could List the mills in a a text box by setting the format to rich text and then putting all the mills into the same field separated by the <br> tag like this.
Mill1<br> mill2<br>mill3
Considerations
1. This will mean that the text box has to be long enough.
2. You will have to concatenate the mills into a single field in you query which may not be feasible.

Answer 4

in a classic in traditional sense, there’s really not such a thing as a many to many relationship between two tables, however by cobbling together related tables one after another, you do at the end of the day due in effect get the same result of a many to many relationship, but technically that’s not what occurring between two tables. In effect you are always working your way down from a parent table to a child table. Those thinking in terms of junction tables are in fact thinking the wrong way.
If a person is allowed to have many favorite colors, then it in poor taste to call that table that simply links their many choices of color to the available colors as a "junction" table. It is far better to simply state that we need a table called:
My List Of Favorite colors table.
The fact the above table may then link to additional tables is moot. In fact it might have more than one column that are foreign keys, and then it not really a simple junction table, but at the day it is doing the same thing.
Anyway, in Access you can most certainly display two continues forms to display data modeled in this manner.
Let’s assume that each weekend we have to take in a bunch of donations from people. This means we have one main table with information about the date and time etc. of this donation event. Our next table would have people and their donation amount. The next table after that would be to take a donation amount, and split up their funds into different accounts. This is a classic accounting distribution problem that just about every accounting package from QuickBooks to whenever has to implement. As it turns out, this classic distribution problem can be solved with very little code when using access.
The trick to modeling these types of forms is to use several sub forms placed into one main form.
The following form shows this:
If you look at the top there’s a main record with information about this batch run and date and time. Now, on the left side is many people and a donation amount. And on the right side is that donation for the one person split out to many different accounts. So I’m displaying many people, and I’m also to display the many accounts that a donation may be split out to .
Keep in mind that access does not let you place a continuous subform inside of a continuous subform. However, you can certainly place two continuous of forms beside each other as the above screen shot shows to model the same affect that you desire.
There’s also surprisingly as mentioned very little code to manage this whole thing.
For the left side continuous form, because the link master and child settings are set to the main form record, then NO code is required for this form to be populated with data. However, for the right side continues form to follow and display the correct Accounting Data for each person in the leftr side continuous form, access will not automatically do this for you . However, a simple bit of code in the on-current event of the left side form will forced access to wake up and note the right side continues form has to be RE populated to display the donation accounts for that one particular person .
The one line of code placed in the left side on-current event will fix this:
me.Parent.Child2.Requery
The link master/child settings on the right side continuous form I use:
linkChildFields main_id (whatever is the name of the field in
this sub-form that is used to relate back to the parent table)
LinkMasterFields [MasterFormLeftSide].[form].[ID] ("masterFormleft" is the name of
the subform contorl you used to hold the continuous form on the left side ).
So, you’ll need a tiny little bit of code, but not a whole heck of a lot, and you now have a screen that displays many information related to many information.

Answer 5

I strongly disagree with "Those thinking in terms of junction tables are in fact thinking the wrong way." in #Albert D. Kallal's answer.
It is true that m:n relationships can't be implemented directly in a relational DB. That is why the one and only sane design of:
+----------+ +---------+
| Patients |--- m:n ---| Doctors |
+----------+ +---------+
... is:
+----------+ +-----------------+ +---------+
| Patients |--- 1:n ---| PatientsDoctors |--- n:1 ---| Doctors |
+----------+ +-----------------+ +---------+
Everything else might work in one way or another but is poor man's relational DB design. And with making compromises at the model design, at the very beginning of a project, the worse is very likely yet to come.