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âŚ
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 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.
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:
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