May 05 2022 08:00 AM
May 05 2022 08:00 AM
Hi, I am trying to create a sub form (employee sub form) that is from the employee table that would pull matching records from a table(cdi_master) based on a field in the main form (dept assigned to in the cdi_master and dept in the employee form/table) . This would normally be an easy task as i have done this before, however the issue is that the fields to match are multi value fields. So if employee 1 records says they are assigned to the Q Dept, then any records that contain the Q value should be contained but the records in the cdi_master could also contain ALL, WH, INV, ETC, Also the employee dept field in the form/table could also have multiple values such as Q, ALL and any record that contains Q or ALL would also need pulled. I am wondering if a query would work and then just pull those into the sub form but i am not sure of the correct expression to use. Any help is appreciated.
May 05 2022 08:55 AM
@Deleted
First, a preliminary observation on the pitfalls of using Multi-Value Fields in Access relational database applications. They create problems of this sort. The way to avoid such problems is to build a properly designed relational table design and avoid Multi-Value Fields.
It is possible to query tables using them. A quick search turned up this starter reference.
I would imagine a search on querying with multi-value fields will yield other sources and examples for you to follow.
I follow my own advice and avoid them, so I have no relevant samples to offer.
May 05 2022 10:46 AM
Thanks, do you have any suggestions on alternatives to the multivalued fields? We dont have the option of only choosing one value. Such as an employee being assigned to whs, and office. or the document record will always be applicable to multiple departments. I am open to any suggestions you have.
Thanks so much:)
May 05 2022 11:00 AM
@Deleted
Yes, I wouldn't suggest it otherwise. To be honest, MVFs are a crutch invented for SharePoint Lists and, unfortunately, imported into Access.
The proper approach is to implement related tables, following the principles of Normalization.
Instead of a field with one or more values in the MVF, you need two tables. The second table, usually referred to as a Lookup table, contains only the values that would have been choices in the MVF.
If you want to allow one or more choices, instead of just a single choice, then the proper approach involves three tables, the main table, the lookup table and a third table between them, usually called a junction table, which relates one or more of the values in the main table with one or more of the values in the lookup table.
There are many, many examples of this Many-to-Many table design available for study. I have one on my website, for example. You can obtain a review more than that, though, to help round out the picture.
The starting point, though is understanding Normalization as it applies to relational database applications.
May 05 2022 11:41 AM
May 05 2022 11:51 AM
@Deleted Unfortunately, my strength does not lie in visualizing abstract description into models. Perhaps this will be easier if you can provide a sample of the accdb in question, with just enough sample data to see how it should work.
May 09 2022 01:46 PM
@George_Hepworth Hi, so i redid my database and I am trying to make it work without using the multivalued fields. I created fields for each of the possible values now in the cdi_master table and created 3 fields for depts. in the employee table. So what I would like to do now, is create a sub form for each of the 3 depts. Each sub form would pull the data from the cdi_master table if any of the depts. match. Is this doable?
May 09 2022 01:50 PM - edited May 09 2022 01:51 PM
May 09 2022 01:50 PM - edited May 09 2022 01:51 PM
Trying to attach the database but it wont let it attach. its only 2.1 mb. So I ended up saving it as a zip file.
May 10 2022 05:49 AM
@Deleted
Thank you. This is going to take some time. Several table design problems manifest here. I see there are still some MVF fields in the table although I thought you had said you'd changed that. I never use them, because of the limitations they impose, so that may add to the time needed to figure out what's going on.
In the meantime, here's a link to an excellent series of blog posts on another problem in this design, Repeating Fields. In this case there are yes/no fields for a large number of categories (I have not yet had time to figure out what they represent). This is a common design flaw inherited from Excel spreadsheets, where that is the only way such data can be handled, even though it's not appropriate for a relational database application in Access.
May 10 2022 05:55 AM
@George_Hepworth Hi, I removed the Multivalued fields that I was trying to do the match to pull from which was the "dept" field. The other fields which is the dept assigned to and standard field in the cdi_master wont be used to do any matches against and will just pull back the data in the fields. In the tests that I did before these fields pulled back the data fine, as long as I was not trying to use a multivalued field to do the matching. I appreciate your help.
May 10 2022 06:00 AM
PMFJI but you may find it worth reading my article Multivalued fields . : : and why you really shouldn't use them
May 10 2022 06:01 AM
May 10 2022 06:01 AM
May 10 2022 06:04 AM
May 10 2022 06:11 AM
May 10 2022 06:17 AM
May 10 2022 06:26 AM
@Deleted
Yes, that is what we are aiming at. Read the blog link I posted, please. There are three or four of them in the series explaining the problem and how to fix the problem. This is a VERY common design flaw, so common that Roger's blog, written years ago, is a staple of tutoring people in table design.
I'm trying not to respond harshly to the complaint that Access lacks the ability to address the requirement. It does, but YOU, the developer need to learn how to use it. That takes a willingness to learn.
May 10 2022 06:37 AM
May 10 2022 06:42 AM
May 10 2022 09:53 AM
Based on my understanding of the context and what the goals appear to be, I made the changes I would expect need to be made (with one important exception, as noted in the attached sample accdb). I also created four sample forms, leaving the one for employees assigned to the training for you.
Note that the design includes what are usually referred to as Junction Tables. These are tables needed to resolve many-to-many relationships. Each CDI document is assigned to one or more departments, and each department is assigned one or more CDI documents, both for training required and training responsibility, assuming I interpreted the existing data correctly.
While it doesn't have the simplistic appearance of checkboxes, this approach is more efficient, more reliable, more flexible and easier to report on.