"condition 3 is not used"

[john]

What does this message mean, when compiling a decision table? Does it mean that no matter what the data input, that there's no logical way to reach the specified condition?

I'm trying to implement some complicated logic (lots of different combinations of OR and AND) using a FIRST table, and I see a lot of these messages when I compile. 

Thanks...

[paul snow]

It means that executing the Decision Table is never going to consider that condition.  It can occur in a couple of ways.

The first way is a bug.  If you use the syntax, 'Perform when called" and an "*" in the table where the 'y" or 'n' would go, then no evaluation is done, and the actions in that column are simply executed.  Unfortunately, I don't have code in place that recognizes that syntax, and since no condition is evaluated, that message kicks out.

The second is that that the table never needs to evaluate that condition in order to execute some action.  Why this is true can be complex and anything but obvious.  For example, if you have a column in your First Table that will always fire before the column where you are using that condition would ever fire, then the Rules Engine will never evaluate that condition.

In the temp folder in your Rules Project, you will get a file called "balanced.txt".  This file holds the balanced representations of your decision tables.  For example, that file contains the following for the Calculate_Group_Size decision table.  If you look at this representation and keep in mind which conditions are not being evaluated, you can often figure out why this is happening.

Calculate_Group_Size

Number of Columns: 15

Type: ALL

   1  y  y  y  y  n  n  n  n  n  n  n  n  n  n  n  

   2  -  -  -  -  y  y  y  y  n  n  n  n  n  n  n  

   3  -  -  -  -  -  -  -  -  y  y  y  y  n  n  n  

   4  -  -  -  -  -  -  -  -  -  -  -  -  y  y  n  

   5  y  y  n  n  y  y  n  n  y  y  n  n  -  -  -  

   6  y  n  y  n  y  n  y  n  y  n  y  n  y  n  -  

   1  x  x  x  x  x  x  x  x  x  x  x  x  x  x     

   2  x  x        x  x        x  x                 

   3  x     x     x     x     x     x     x         

If you still can't figure out the deal, then you can send me your decision table by email, and I will explain what is going on.

Paul

[john]

Thanks Paul.. yea, I can see lots of lines in my balanced.txt that are all dashes all the way across...

Sometimes I try sprinkling "N" here and there in the conditions, instead of just leaving the cells blank aside from the "Y" cells. Sometimes it helps, but I don't think I have a handle on when to use "N" and when not to. 

[paul snow]

You really should simply be writing the logic exactly as you understand it.  When you see conditions that are not being used, then simply think hard about the cases and the logic.  Just like Mass falls out of Newton's equations for motion, there are times that conditions that are present just don't actually change what actions you should take.

In the end, it is okay if conditions are not really used.  It isn't an error.  But it is an indicator that you should review your logic.

Paul

On Fri, Jan 13, 2012 at 4:18 PM, john <mr.joh...@gmail.com> wrote:

Thanks Paul.. yea, I can see lots of lines in my balanced.txt that are all dashes all the way across...

Sometimes I try sprinkling "N" here and there in the conditions, instead of just leaving the cells blank aside from the "Y" cells. Sometimes it helps, but I don't think I have a handle on when to use "N" and when not to. 

It 

[John Lynn]

The problem I think is: this particular decision table has lots of rules like this to evaluate: 

set to 7 if: [5000 to 10000 blivets OR 5000 to 10000 flabbers] OR [Vote_XX = "1-10"] OR  [Vote_YY = "3"]

set to 8 if: [[>10,001 blivets OR >10,000 flabbers] AND Vote_XX = "1-10"] OR 

    [[>10,001 blivets OR >10,000 flabbers] AND Vote_YY = "3"] OR 

    [[>10,001 blivets OR >10,000 flabbers] AND Last_ZZ =  otherThing] 

    

set to 9 if: [Vote_XX = "1-10" AND someOtherThing] OR [Vote_XX = "1-10" AND YetAnotherThing]

Horrible example, but the point is that there are lots of ORs and/or ANDs using the same data in many of these decisions. 

An OR is just a set of condition columns that all end up executing the same action, based on different conditions

And AND is a condition column with more than 1 "Y" vertically

You said "You really should simply be writing the logic exactly as you understand it.  When you see conditions that are not being used, then simply think hard about the cases and the logic.  Just like Mass falls out of Newton's equations for motion, there are times that conditions that are present just don't actually change what actions you should take."

But how would the compiler know what sort of data will be coming along? If the data is varied enough, all the conditions will come into play, no? 

[mauro]

I noticed also the following case that is returning Condition X is not
used:


if I put an OTHERWISE condition with *

example:

ProductSelector.ErrorCode==0 N Y Y Y Y
Prot.Ind=='Y' Y N
Preg.Ind=='Y' Y N
CurrentDate is null N N
CurrentDate is greater than DateValidity N Y
otherwise *

I get condition 6 is not used. Is it the same bug that you mention
about Perform when called?

ciao

> > Thanks...- Hide quoted text -
>
> - Show quoted text -

[paul snow]

Yes. That is a bug.