When is RowMod required?

Apologies if this is a dumb question, but I am a little confused as to when a RowMod setter is required vs. when it is not.
In my function, I originally was using the Field Setters to set my fields, then call the update method of the BO. In this example, the BO is UD100. There is no column in the field setter for a local variable (which is the UD100 Tableset)

I could not get it to work with this method, so I tried using the Update Table by Query, which does have a RowMod field. After this widget is configured and the update method on UD100 is called, the record is updated.

In the second portion, I create and update a new UD100A record, but I strictly use the Field Setter widgets. This updates just fine without setting a RowMod. Is this because the RowMod value is implied by the nature of the first call to GetANewUD100A?

When you call GetNew the row that is returned contains a RowMod =“A”

As a pretty good rule of thumb (though it has exceptions)
GetNew will return a rowmod of A
So no rowmod is require on the (first) call after this

If the call modifies the dataset there are pretty good odds that you’ll need a RowMod

The only time you may not need a rowmod is if the parameters passed to the method make it pretty clear which row you are intending this action to happen upon

For example if the call takes OrderNum, LineNum and OrderDatSet then the system knows that whatever needs to happen needs to happen to OrderNum XX Line YY

However if the call is just Update(orderds)… there are many records in orderds (OrderHed, OrderDtl, etc) so you need to tell it what rows you need updated…

Hope this helps.

1 Like

That does help, thank you. In this scenario, it seems the only way to indeed set the RowMod is by use of either an “Update Table By Query” widget or custom code. Is that correct? I realize the Field Setter is interacting with a local variable passed out of the initial GetByID, so it would probably make sense no RowMod field would exist on that.

Yeah I avoid those widgets for the most part. But yeah probably the SetField isn’t triggering the RowMod being set.

And yes the GetByID dataset is returned with no RowMods (since nothing has been modified)

Haha yeah I am just trying out the widgets to make it the “epicor” way, but it definitely is more familiar to use regular ol’ code

Yeah widgets are nice but each of those widgets generates one (or more) methods… and it isn’t the cleanest code in the world.
Nothing “wrong” with it , the code is generated by a computer so they are doing the best they can, but it isn’t the most efficient thing in the world.

1 Like

Jose did a great job explaining this. In a BPM workflow for example, I like to modify the data in the tt set using widgets, then at the very end of the routine (say right before an update method widget) have a custom code block for just marking the rows “dirty” (RowMod “U”).

There is also record deletion, and I have found some objects let you use their “DeleteByID” method, while some have a “DeleteByID” method but it does not work, and instead you must set the rowmod to “D” for delete then call the BO’s update method.

In a BPM you can also use the SetRowState method on a data row:

myDatarow.SetRowState(IceRowState.Updated);
1 Like

Thanks jeff good write up. I think the hard part is when attempting to use the widgets it’s a bit cryptic and unintuitive, which is probably just because I’m more comfortable with the code side

I agree. For more complex BPMs I tend to go full code, but for simple things like defaulting a few fields I go with widgets.

If i need to use a loop in some logic…forget about widgets entirely haha

1 Like