I’m working on a BPM and one of the conditions that I am trying to use always seems to lag behind the change. For reference this is a pre-processing method on EngWorkBench.update. I’m in 10.0.700
I want to see what part class a part is in when I change a related operation in the method (ECOMtl table) and set the scrap rate accordingly. The ClassID for the part is not in any of the TT tables, so I am trying to use the “Number of rows in the specified query is more than 0” to try to signal when they are in the list of the affected classes.
In the designed query I tied the ttECOMtl table to the Part table with company and part number and filter the part table for any parts in the list of classes using the “IN” operator (or whatever you call those functions)
For some reason, whenever I try to use this condition, it will return a row when it shouldn’t when being changed from a state that it should (more than 0) to when it shouldn’t (o rows). I can return the tt tables in the message box and with the info that’s in there and see that it should be returning 0 rows. After the next change from a 0 state to another 0 state, it works fine. And from a 0 state to 1 or more it works fine. But from a 1 state to 0 state it passes the condition true when it should be false.
EDIT:: it is just always lagging behind. When it should return more that 0 the first time, it doesn’t but it does the second time. The same when it should return 0 for the first time, it doesn’t but it does the second time.
Hopefully that makes sense
I have seen this behavior when trying to use this condition is other areas as well. Does anyone have know what I might be doing wrong to make this behave this way?
Thanks,
Brandon
Screen shot of the designed query
