Many-to-Many
Normalizing Data

Kevin, these 10 fields v descriptions are always different, they are not to be chosen. They are random comments depending on the type of cabinet that is built. Is this also going to be with a many to many.... Those descriptions must remain with, for example, cabinet 1 per 10 descriptions....

Can you share an example relating to something we can understand?

see pictures. It is an excel file that I want to convert to access. It concerns a catalog for kitchen cabinets "about 10,000 pieces and will probably be 20,000 pieces that must all be included. Each cabinet has its own name, dimensions, categories and separate descriptions" circled in red. Each description can be different, you cannot attach a combo box to it, I have split all data into tables as much as possible as normalization prescribes, I am a bit stuck with which relationship to apply here, one to many or many to many for the Notes. I've watched a lot of videos but I can't figure it out. I'd love to hear from you. :)

It should also not be a list listbox where all notes are together, later an Excel must be exported from it on 1 line in cells to import it into a drawing package Winner and WIDOOCA. See photo attachment

Subforms

Ok, I'll look at it, I'm not supposed to import the data from Excel, structure is wrong and a lot of codes are going to change as well. It's just the right relationship I need to have.

If these descriptions are something that the user types in and doesn't select from a list, then you're probably best off just using a one-to-many relationship and making a table to hold the descriptions. This is similar to the relationship in my database between customers and contacts. I would create a subform and let the user type in those descriptions in the subform. It's really just as simple as that.

Richard, most fields have to be chosen with a combo box, only KastT notes, Price groupT, Order codeT have to be entered by the clerk himself. So the rest is all in the table as fixed values. To be able to distinguish between types of cabinets, I have created an XXX table. KastXTypeT, if I understand correctly I should create at least 8 nested subforms such as Nested Continuons Subforms.

I'm looking at the descriptions, so remove descriptions from KastT and a new DescriptionT table.  Thanks

The strange story of Access in my opinion, you start with full courage to learn Access, you find that Access is not that easy and you start looking for a good learning environment. Then you come across Computer Learning Zone and you're off. Like a real student, you start at the beginning and follow all modules neatly. After a while you start to feel that you can work reasonably well in access, you watch all the videos, do all the exercises and it works. You are proud. You are already working on expert 17 and everything is going well. One day your boss asks you to create a database with the work data because everything is in Excel and it is becoming cumbersome with multiple copies. You start with a lot of courage and you immediately encounter the first stone: normalization. The most important thing before you can start. That's what I and I think many others encounter. I would think it would be a good idea if there were several examples of normalizing different examples. This way everyone can recognize their own thing and learn something from it. It's just an idea but I think it would mean a lot. A good base is the start of a good database.

I note that "skills Test Quiz is still in the works for a long time, we can't set up a platform with basic oef for standardization for our members with which we can hone our skills and share them with each other. You could start from a situation of an order form and create a database for it with the necessary tables and relationships. I'll make an example