I don’t allow my few hairs that I have left to be split over this… I only did the “Contains” as an optional way to do things… I have done the time tests… sometimes in the name of future maintainability, I will do the “contains” method, but most of the time, I use the x.RowMod == “A” or x.RowMod == "U"
did you do a time trial using the (x.Added() || x.Updated()) version? I have always been curious as to what this turns into… i would imagine that x.Added() turns into x.RowMod == “A” during compile.
the short circuit during the comparison does save time, but also points out that if you REALLY want to save some time, the first condition you test for needs to be the one most commonly rejected/accepted (depending on if this is an OR or an AND)… because when the condition is met, it will skip the rest.
Thanks all…
Pretty Close: Removes case-sensitivity and also makes sure the row is not null (not sure if it ever would be). In case someone passes in “a” instead of “A” or “u”
What I find surprising is that in the .Updated() and .Added() they are hard-coding the constants again U or A and not using IceRowState enum, unless thats just how dotPeek displays it.
Also out of scope of the topic; but UBAQ BPMs also manage a “P” RowMod for Processed or Published or something.
I think of it as Patch but maybe that’s just the old web dev in me LOL
Epicor uses RowMod = “P” in updatable dashboards, but I have not seen it used anywhere else.