REFERENCING Form's instances controls (2 Viewers)

Here is an explanation of what the OP is attempting to do with ACCESS. It appears they are trying to track garment parts to be used to make garments, although I do not speak the language used in construction the tables and fields:
View attachment 120579
The OP has no relationships in the database between the two tables, so basically, they have two tables they are using like spreadsheets. The OP believes that some code they got off the internet will somehow make this work. It will not.

@LjushaMisha:
Given the description in the Readme table, you need to construct this project as a relational database which is what ACCESS was designed to be, based upon the requirements outlined in your Readme table included in the project. No code will help you do this.
Dear LarryE,
I have tried to make relations, but the only way was to make table for each LEVEL but I didn't find it "user friendly". That's why I have in "tblSestav" two fields (Ses_Nivo and Ses_Nadrejen_Id) - they actually work as connection between two tables. "Ses_Nivo" could be also called LEVEL and "Ses_Nadrejen_Id" could be called SUPERIOR PRODUCT ID.
From attached file to June7, you can see IT WORKS also in that way. Although it is maybe wrong from Access master view.
 
I would look at using a treeview for this. This is a self referencing form with multiple levels.
Click on the node you want and see it s details on the right, and details for its immediate children.

I discuss in detail working with hierarchical data and self referencing tables.
I would look at my BOM database to see how this works.

move.png


To make this work I had to change the relationships as already mentioned.

So you need you table of Possible items which you have.
Then in your assembly table you need a unique ID for each item in the assembly, not just a product (artID) key.

I have tried to make relations, but the only way was to make table for each LEVEL but I didn't find it "user friendly". That's why I have in "tblSestav" two fields (Ses_Nivo and Ses_Nadrejen_Id) - they actually work as connection between two tables. "Ses_Nivo" could be also called LEVEL and "Ses_Nadrejen_Id" could be called SUPERIOR PRODUCT ID.
Using a properly designed self referencing table the table structure is extremely easy. Using a tree view the UI becomes extremely user friendly. If interested I can talk you through doing this. My code makes this extremely easy. If you want a detailed course.


at 24:29 I demo the bill of materials (systems and assemblies)
 

Attachments

Last edited:
Dear LarryE,
I have tried to make relations, but the only way was to make table for each LEVEL but I didn't find it "user friendly". That's why I have in "tblSestav" two fields (Ses_Nivo and Ses_Nadrejen_Id) - they actually work as connection between two tables. "Ses_Nivo" could be also called LEVEL and "Ses_Nadrejen_Id" could be called SUPERIOR PRODUCT ID.
From attached file to June7, you can see IT WORKS also in that way. Although it is maybe wrong from Access master view.
You still need to construct your project using the relational model.
  1. Each product consists of multiple wardrobe parts
  2. Each wardrobe part consists of multiple components
 
ou still need to construct your project using the relational model.
  1. Each product consists of multiple wardrobe parts
  2. Each wardrobe part consists of multiple component
I do not. Everything is a component and goes into a single self referencing table. If that component is an assembly then it has related children. But I never build a separate table for components. You can but it only complicates the data structure.
 
I have tried to make relations, but the only way was to make table for each LEVEL
That is just one way. Another is to have a field that shows who the parent is and what level they are at.
 
Assembly/manufacturing type database is probably most difficult to structure and manage (along with family tree) because of recursive nature of data relationships - common topic in forums.
I agree with other comments, you need a better understanding of relational database concepts before continuing your efforts.
 
That is just one way. Another is to have a field that shows who the parent is and what level they are at.
Technically parts in a part table have three types.
End Items (no parent part, may or may not have child parts)
Components (both parent and child parts)
Details (parent part but no child parts)

Because components can have more than one parent, I always use two tables for this schema. One to hold each unique part and the second holds the relationships.
 

Users who are viewing this thread

  • Back
    Top Bottom