In general terms, it sounds like I would have a main form with all of the controls you'd want to search by, arranging them from left to right starting with the major criteria (main parent) if there is such a relationship. On this form, a subform datasheet or continuous form (cf) based on a query that returns records according to the criteria provided by the main form. One advantage to the cf is that you can easily reference a particular row, so if you put a command button in the detail section (as part of the record) clicking it can reference the row it's on. Useful if you'd want to open a report based on one particular row as long as you don't mind a repeat of the button on every row. Possible to do this with one button in the cf header or footer as well, but sometimes it's far above or below the desired record and may not be as intuitive.
The most difficult part of the approach is having to deal with controls that only contain values for the query part of the time. If Null, they usually have to be ignored to produce the desired records. Using vba, the main part of a sql statement is written and depending on which of the controls contain data, the WHERE part is appended to concatenate the remainder. Then the query is opened/executed or the report/form is opened. There are lot's of examples on how to create such a search form.
While I did work in a steel mill, my background was maintenance, so I'm guessing that HEAT is a parent value from which many slabs might be produced whether or not it is continuous casting or ingots. So SLAB is a child of HEAT; MTR is material test report and is specific to a particular slab; THICK is a characteristic of a particular slab. Thus I might arrange combos, left to right, as HEAT, SLAB, THICK and MTR. These controls would have row sources but not control sources. As mentioned, check out search forms.
