I’m trying to get some ideas on how to evaluate some logic conditions and return a result based on the these conditions. Once I have an approach, I should be able to figure out how to code it.
I’m working on an application where we will be recording results of up to 20 test samples of different materials. Not all materials have the same number of test samples, and if certain samples fail initially, there may be multiple retest records generated, one of which may pass criteria. Each test sample represents a quantity of 10 pieces of material, which may pass or fail depending on the result of the test sample, although testing may not be performed on each sample number. For example, representative sample tested for a quantity of 120 pieces may be samples 1, 4, 8 and 12. If sample 1 passes and sample 4 passes, then samples 2 and 3 are considered good as well, and the pieces associated with samples 1, 2, 3, and 4 are considered good (40 pieces). If sample 8 fails, then the samples between 4 and 8 canot be considered good, unless additional samples are tested (5, 6, 7), however it may be decided to just discard those unknown pieces instead of spending time testing the additional samples to narrow it down. If sample 12 tests good, we may test sample 10 even though it was not originally planned to be tested, just to see where the good/bad cut-off is. If 10 tests, good, we can say that pieces represented by samples 10-12 are good, bringing the number of passing pieces to 70 (40 from samples 1 & 4, and 30 from samples 10 & 12).
How would you approach this problem in terms of coding. I figures I can build a lookup view containing the sample number and pass/fail status. A summary form will be created to returnn the results of the lookup into a field and I can separate the returned data into a text list identifying each sample tested and the corresponding results. Now I just have to figure out how to evaluate the list, codewise, to determine which pieces (1-10, 11-20, 21-30…191-200) are good based on the interpolation of the pieces between available samples which were tested. Keep in mind there may be 3 or 4 retests of the same sample, one of which may be a passing results, but all could be failing results.
I think using the @Formula language and loops you might be able to iterate through from 1 - 200 and keep track of a flag that is set to Pass/Fail.
However, I would probably just code something in LS and if you want to have the data visible in views then make some reporting/viewable fields that LS will write to. So you might have Pass, Fail, and Unkown fieldnames and you jam in all the numbers between 1 and 200 into each, appropriately.
But in any case, I imagine you have to simply walk through your list of 1 - 200, and for each number check the TestSample field to see if that sample was tested, and, if so, the result. And if not, then do your logic thing (above) to determine whether this is a P/F/U.
Thanks for the reply…I think I have something working, but it needs more testing. I was able to use @formula language, but I had to create a bunch of fields to help me visualize what’s going on.
Basically, I set up one field to hold the returned test sample list from the lookup. I then created a table of 20 computed fields to extract individual values from the list. Each field represents the final test status of a particular sample number. If a sample was tested more than once, the value returned to the field is the last recorded test result for that sample number. So the field resolves to eiither pass, fail, or nothing.
I then created another table of 20 fields for the pieces represented by the samples. First field is for pieces 1-10, second field for pieces 11-20, etc. In each field, I put a number of conditional statements in order to return a value of good pieces (range of 10 pieces) or nothing if it can’t be determined if they’re acceptable based on the tested samples. So basically, for pieces 1-10, we look at the first sample tested and see if it’s a pass. If the first sample is a pass, we look at the next sample field to see if there’s a result. If no result, look at the next sample field, and so on, until you obtain a result. If the result of sample 4 (for example) is a pass, then the associated pieces must be good because sample 1 result was good, and sample 4 was good. I did this for each field representing groups of 10 pieces, and then added a summary list field to return all field values associated with good pieces.
It’s a lot of if statements, but it seems to work so far.