Form based on multi-table form (many to many relationship) (1 Viewer)

Apples241

Registered User.
Local time
Yesterday, 20:09
Joined
Aug 29, 2016
Messages
54
**Poster's Edit 10/11/2016 8:45 a.m. - the new, correct database has been uploaded to the post. Pardon any inconvenience. I would appreciate any help.**

**Poster's Edit: Pardon the error, but I have uploaded the wrong database. I have removed the attachment and will need to upload the correct one tomorrow.**

I'm using Access 2013 and am trying to create a database that houses info from two large spreadsheets, the Schedule and the Design spreadsheets. They track the schedule of what nodes are being segmented and when, along with the design of those nodes, i.e., the transmitter and receiver settings, etc. (for the telecommunications industry).

I've never created a db from the ground up and I am having a lot of trouble with creating the database so that I can update my data in my form and also add new records via my form.

I've created a form and added a tab control where I'm going to put the fields from the Schedule on the 1st tab, called 'Schedule', and about 8 fields from the Schedule on the 2nd tab, called 'Design', along with all of the fields from the Design table.

I'm just working on the Schedule tab right now and have added the fields from the Schedule to the 1st tab on the form. I can update the existing data, but:

1) I can't a new record and my junction table be updated. I just get 0's for all of my fields. Do I have to manually update those each time I need to add a record?

2) Also, all of my fields except the NodeA and NodeB need to be drop down menus. I tried adding the Design Status field as a drop using the Combo Box dialog box. I chose:
a) to get the values from the another table, the Design Status table.
b) the selected fields are the DesignStatusID and the DesignStatus fields
c) sorted by the DesignStatusID field
d) kept the key column (primary key) hidden
e) remember the value for later use (I didn't know what to choose here)

I then went to properties and made the Control Source to be the DesignID, but now when I try to add a new record and select a value in that combo box, it said 'Cannot Add Records, Join key of table 'tblJunction' not in recordset'. I added the DesignStatusID field from the Junction table to the form and hid it so that it doesn't show. How do I fix this?

I've attached my test db, but also here is my form in design view (the Design Status text box and combo box are side by side just as a test).



(The link seems broken, so here's an alternative): https(colon)//drive.google.com/open?id=0B9IyKJSJ52ghcklFUF9PMFYzLWc)

The properties for the Design Status combo box are Control Source: DesignStatusID and Row Source is:
SELECT tblDesignStatus.DesignStatusID, tblDesignStatus.DesignStatus
FROM tblDesignStatus
ORDER BY tblDesignStatus.[DesignStatusID];

Here are my relationships in the Test db I've created, many to many relationships. My actual db will have many tables to the right of the Junction table b/c the Schedule has many fields, like Rx Settings, CMTS Type, Date of Activity, Confirmation Number, etc., that need to be normalized.



(The link seems broken, so here's an alternative): https(colon)//drive.google.com/open?id=0B9IyKJSJ52ghTUNJeElsV2FGdXc)

Thank you in advance for help.
 
Last edited:

MarkK

bit cruncher
Local time
Yesterday, 20:10
Joined
Mar 17, 2004
Messages
8,198
I think you have misunderstood how a database works. Maybe you want to google "database relational model" and do a little reading first, but your table design just looks like a spreadsheet, and Excel thinking in database design just doesn't work.

Looking at your data, I would expect you to have a table called Hub, and it looks like a Hub might have multiple Nodes, so you probably need a table called Node. Your CMTAs also look like discrete objects that belong in their own table, because of all the repetition in the data. Whatever this thing is...
Code:
cbr01.cinco.tx.houston.comcast.net
...should probably be a row in table with Long Integer ID field, and then be linked to other related objects.

A database system is a model of a reality, not just a flat file of the data involved, and if that model does not accurately represent the reality you are concerned with, you will never gain that advantages that a database implementation can offer.
 

Apples241

Registered User.
Local time
Yesterday, 20:09
Joined
Aug 29, 2016
Messages
54
I think you have misunderstood how a database works. Maybe you want to google "database relational model" and do a little reading first, but your table design just looks like a spreadsheet, and Excel thinking in database design just doesn't work.

Looking at your data, I would expect you to have a table called Hub, and it looks like a Hub might have multiple Nodes, so you probably need a table called Node. Your CMTAs also look like discrete objects that belong in their own table, because of all the repetition in the data. Whatever this thing is...
Code:
cbr01.cinco.tx.houston.comcast.net
...should probably be a row in table with Long Integer ID field, and then be linked to other related objects.

A database system is a model of a reality, not just a flat file of the data involved, and if that model does not accurately represent the reality you are concerned with, you will never gain that advantages that a database implementation can offer.

I'm sorry, I attached the wrong database. I have read a lot and revised it many more times beyond what you saw. I will need to reload the correct db tomorrow. Thank you for your help and pardon the error.
 

Apples241

Registered User.
Local time
Yesterday, 20:09
Joined
Aug 29, 2016
Messages
54
The new, correct database has been added to post now. Thank you for any help; I would appreciate it.
 

Attachments

  • Access Project Test_10102016.accdb
    704 KB · Views: 116

MarkK

bit cruncher
Local time
Yesterday, 20:10
Joined
Mar 17, 2004
Messages
8,198
I don't think you need a table called DesignStatus that contains the two values True and False. Rather, just put those values directly in the related table, so delete the Junction.DesignStatusID field, and replace it with a field called IsComplete. Creating a link costs you a four byte (Long Integer) key overhead in each table, but if the data you are linking to <= the cost/size/complexity of the key itself, the link is a waste of energy. Links are used to relate to complex, not scalar data, or where there exists a many-to-one relationship.

This is a similar case with your table TX. These are just scalar values. How are they related to the junction? You have the TX table as the parent, so for one TX, you might have many Junctions, but what does that mean in the real world? What is a TX and how does it serve as a parent to the Junction?

The Hub has two nodes, A and B. Is a Node ever added later than the Hub? Can a hub have three nodes, can a hub have one or zero nodes? Will you ever need to run summaries on ALL nodes? If you answered Yes to any of those questions, nodes should probably be in a child table, related to Hubs.

Keep in mind that in the real world your data has a shape, and in a database we are designing a custom box to fit the shape of your data. If you build the box incorrectly, your data will not fit, and your system will be a constant fight. But if you build the box correctly, you will be surprised how smooth your system will work.

Hope this helps,
 

Apples241

Registered User.
Local time
Yesterday, 20:09
Joined
Aug 29, 2016
Messages
54
I don't think you need a table called DesignStatus that contains the two values True and False. Rather, just put those values directly in the related table, so delete the Junction.DesignStatusID field, and replace it with a field called IsComplete. Creating a link costs you a four byte (Long Integer) key overhead in each table, but if the data you are linking to <= the cost/size/complexity of the key itself, the link is a waste of energy. Links are used to relate to complex, not scalar data, or where there exists a many-to-one relationship.

This is a similar case with your table TX. These are just scalar values. How are they related to the junction? You have the TX table as the parent, so for one TX, you might have many Junctions, but what does that mean in the real world? What is a TX and how does it serve as a parent to the Junction?

The Hub has two nodes, A and B. Is a Node ever added later than the Hub? Can a hub have three nodes, can a hub have one or zero nodes? Will you ever need to run summaries on ALL nodes? If you answered Yes to any of those questions, nodes should probably be in a child table, related to Hubs.

Keep in mind that in the real world your data has a shape, and in a database we are designing a custom box to fit the shape of your data. If you build the box incorrectly, your data will not fit, and your system will be a constant fight. But if you build the box correctly, you will be surprised how smooth your system will work.

Hope this helps,

Thank you, I didn't think about that re: the Design field. And, yes, I should have the nodes in a child table. I used to have it that way but thought that the nodes are always part of their own particular hub, so I put them in a table together.

I appreciate your help.
 

Users who are viewing this thread

Top Bottom