BIRT expression builder, multiple AND/OR comparisons

[tjgittiup]

Trying to compare multiple fields to determine Y/N… can you please help me understand if I should use one expression for this or have to break it up somehow or aggregation/groups? What am I missing here? too many arguments?

if (row["Field 1"]!=row["Field 2"])
OR (row["Field 3"]="Y" && row["Field 3"] == row["Field 5"])
OR (row["Field 3"]="Y" && row["Field 2"]="Y")
{"Y"}
if else {"N"}

Also, if anyone has any great, quick, simple cheatsheets to recommend, or LinkedIn Learning/YouTube videos, on creating reports, expressions, even just operation basics, for Java or whatever this is. :) PLEASE let me know. I'm stumbling through this on my own.

All links to example videos and report files seem to be broken here: https://eclipse-birt.github.io/birt-website/docs/template-introduction

Many thanks!

[speckyspooky]

The problem is that you have added 3 issues there:

1. used SQL logic operator instead of JavaScript - used "OR" but "||" needed
2. used SQL compare operator instead of JavaScript - used "=" but "==" needed
3. used rounded brackets are set in wrong order
4. the if-else-case is wrong

Best practice:

• avoid spaces in column names
• use same alias notation of columns like all upper or all lower
• use more structired scripts and use more spaces between the operators to get a better overview

Your script renewed:

var result = null;
if (   row["COMP_PLAN#COMPENTRY'COMP_ENTRY_STR_CUSTOM8"] != row["PD Promo"]
    || row["Progression Flag"] == "Y" && row["Current Job Code"] == row["Prop Job Code"]
    || row["Progression Flag"] == "Y" && row["PD Promo"] == "Y"
) {
    result = "Y";
} else {
    result = "N";
}
this.value = result;

If your default result is "N" - you can shrink it:

var result = "N";
if (   row["COMP_PLAN#COMPENTRY'COMP_ENTRY_STR_CUSTOM8"] != row["PD Promo"]
    || row["Progression Flag"] == "Y" && row["Current Job Code"] == row["Prop Job Code"]
    || row["Progression Flag"] == "Y" && row["PD Promo"] == "Y"
) {
    result = "Y";
}
this.value = result;

[hvbtup]

I'd like to add that (as a best practice in my personal opinion) I use all uppercase column names without spaces like BEST_PRACTICE for those columns that are a SQL result columns and CamelCase names for those columns or bindings that are computed columns and aggegration columns.
By using this convention, it is always clear if a column is an SQL result set column or computed within BIRT.