Couldn’t use an “Update Table by Query” widget, setting the RowMod field with an expression ("U"), and ignoring all other fields?
5 Likes
The man right there!
Yes, you sure can.
Having said that, the “283 bindings created automatically” makes me wonder how efficient that is… 
Man… I’ve gone to the dark side now. It’s harder to go back…
2 Likes
If Postman is any indicator, there is no clear difference. Either way is 400ms +/- a bunch. For me, of course.
1 Like
This is SWEET @JasonMcD I want to try it too now!
I remember trying the parser some time ago. I will have to re-visit it.
This week I have been playing around with rest calls and Jose’s Nuget.
I am trying out functions now as Mark Wonsil suggested so I can take advantage of them using a rest call. I will need this parser potentially. I am trying to create a new inventory transfer 
Thanks for the post Jason, pretty inspirational.
2 Likes
Lol for sure - if I can do it, anyone can.
Yep, gotta credit @Mark_Wonsil for his RELENTLESS push for functions!
Yes, yes you will. Yes you will.
2 Likes
Biggest thing is what I never wanted to admit was true, but I always knew it. From that first post I linked to:
But with the tracer, it’s survivable. Just know that you need to fill in the parameters AND possibly do some field setting. But not always - a lot of the diffs are done by the methods without you telling it, like job part number. But then some need your help, like labor hours.
And you may need to set a stinkin’ row mod.
ha! you can lead a horse to water as they say. I grow breathless saying
Glad you saw the light and it helped!!! Happy Dance 
1 Like
@JasonMcD if I have a TableSet and I want to get one of its values after it runs through a business logic call, do you know how to do that?
i.e. I created a variable InvTranDataSet as type InvTransferTableSet.
I have been passing this along through the different business object methods (that I saw in a trace) as the dataset param and I am trying to verify that the dataset is indeed changing after every call as I see in the trace.
How would I extract a value from the table set? I keep trying to get a row from it, but it says:
EDIT I was able to assign it to a variable and then use LINQ to get it from there…
1 Like
Wow!
I’ve just finished making a customization that updates all labor details associated with an operation when one labor detail is updated so that split burden is correct when a labor record is corrected through time management so I know how much of a pain these labour details are.
I think mine would have been impossible with no code though, so respect!
1 Like
I am curious how you solved this.
I mean, I am sure you tried this with the expression editor in the Set Variable widget. I used that to return the LaborDtlSeq (just for curiosity) and it worked fine. You know, for my situation yesterday it worked. Today I’ll try something else and it probably won’t work…
I gather the issue is, what if you have multiple rows in the dataset? Just a guess.
Also, here is where it gets muddy (muddier) for me. The post I used as a guide had this block of code:
But I used:
MyDataset.LaborDtl[0].RowMod= "U";
I tried Brandon’s code and got an error in the designer.
So I used a format more like Jose’s Trace Parser showed (there’s no “LaborData” portion):
It worked, so I guess that makes sense?? 
I did this:
var test = InvTranDataSet.InvTrans;’
then you can use LINQ to get your values from there.
But you can’t make it drink… but if you feed it salt it will drink every time
@JasonMcD thanks for the inspiration yesterday.
I finished a BPM on ABCCode.Update Post processing that transfers 10 units of inventory from one warehouse bin to another. I hardcoded everything that would normally be put in by a user (dynamic data) such as part number, warehouse, lot, etc… I am still learning how it all fits together. I also don’t think I am doing the row mod update correctly, do I really need to add it before each call?
What I wanted to ask you @JasonMcD is what you do with some of the business logic calls where the methods don’t make changes to the dataset, but rather they return a message (which usually would result in an exception being thrown)? When you trace something there will be methods called that just return a message, or they are doing some type of check… If those were ran natively in the application some sort of warning message or even exception pops up. Did you have any of those calls when you traced the labor method? What did you do with those, did you handle them like the application does?
This is where some experience comes into play about knowing what you can and can’t skip. A lot of the checks are going to be checks to make sure someone didn’t fat finger something. But if your data is coming from a database lookup, there isn’t anyway for the data to get typed in wrong. So some of those things you can skip. But you have to think about why the check is happening to know if you can skip it or not. There aren’t really any hard and fast rules on that unfortunately.
3 Likes
Thanks Brandon. I have heard this from many people. Is there any way to help aid in the process of “thinking about why the check is happening” other than assuming or taking a guess at it? Could you decompile with ILSpy to get a better look? Maybe it is just best guess.
And say you skip over those methods Brandon, could something still pop up in a later method call as a result of skipping over the data validation calls?
@JasonMcD did you end up using any of the calls that were checking data?
Glad an expert weighed in.
But that’s what I deduced, too, is all of these BOReader calls seem to be for generating a dropdown and that sort of thing. Like you said, if you are preventing that in your own UI, then it should be clean. 
Man, I am just getting started on this! I’m with you - hoping it works with the minimum needed.
1 Like
Possibly. Remember, all of this code is written by people, so it’s not perfect, and not all possibilities are taken into account all of time, and it’s not 100% consistent from one method to another. In theory, the Update method should prevent you from shooting yourself in the foot. But it doesn’t always work out.
And yes, decompiling and testing with things like the BL tester are all things that can help you understand what’s going on. It’s not too often then you will get through all of the testing and have nothing blow up and create time bombs for later.
1 Like
The other thing I see in all of this - and this should be no surprise - is that a trace is only as good as the scenario you trace.
So, like Tuesday, I traced a labor entry with quantity, then Wednesday I tried it with an operation that prevents quantity, and it failed, because, why was I calling a DefaultQty method with a zero quantity?
So I guess my point - again, an obvious one - is that the trace doesn’t explain the logic tree. It’s just a record of the path you went down that day.
2 Likes
Yeah I love time bombs. I had one cooking (built by someone else) that was a wicked labor reporting customization, super sharp, but little did we know it was not updating in the proper fashion so it was unintentionally reversing backflush transactions for an unrelated job and operation. Whoops! I know I have some of my own that I created too, I just didn’t know it at the time.