Seems fine to me.
Tested on 2022.2.13–are you still on 2021.2?
Although, if support is testing it, they should be on the latest… 
I guess it’s not an apples-to-apples test as my calculated field is using SellingQuantity * DspUnitPrice since I don’t have the UD field you’re using, but I wouldn’t think that would matter.
I’m clicking the lines link in the left nav that brings up the the lines page, not scrolling down to the liens grid. Don’t know if that makes a difference. 2022.2.14.
See I AM NOT CRAZY lol
Well, let’s not get carried away. 
So, setting %dataset.SalesOrder.hasChanges% = false is, uh… NOT a good idea. Hahaha
It just totally breaks the tree. Completely.
More failures:
TransView.checkForOrderChange to false breaks the tree as well. Setting it to false, doing the calc fields, then setting it back to true also breaks the tree.Les sigh.
Good to know!
Whelp.
My layer is fuuuucked.
Been there. Sorry
Lol, not a big deal. This was just a fluff layer for testing.
Ok I will have to try this now!
omg you fixed it, amazing!
Makes me wonder if that should be standard when adding columns to grids?
I notice native Epicor doing it too in places.
It seems counterintuitive since the data isn’t actually being updated in the database, but maybe that’s what it needs. I still think it should be way simpler to add a calculated field to a dataview, like just throw an expression box in the dataview screen.
Agreed. There’s a lot of room for improvement.
I can see the flow, though. They’re using the view’s hasChanges property to know whether to update between switching rows. Doing the row-update on a row to add the values triggers that to true, so it thinks it needs to update, but with a calculated column–or even just an added one from a different table–nothing is actually changing, so when it tries to update, it fails.
That being said, I’m still a bit unsure as to why it’s barking at OrderHed when the column was added to OrderDtl. MasterUpdate doing MasterUpdate things, I guess.
For sure–this would be ideal.
So, I have some calculated columns in my BAQ (both of the columns I need added 
) that seem to be causing the grid to completely break. I have used your method before, Hannah, to add columns to grids and it worked well (thanks again!). What I’m not sure about is my columns from the BAQ are using case statements, the final result is a string. Since this is breaking my grid, I’ve come to this thread and tried to set my iterate event up the way you’ve done it here and it’s not letting me save or preview the changes.
Do I need to add my case statement to the expression field you all are using here? the case statement is using two tables so I would probably have to add a second dataview to get that to work here.
Ever run into anything like this? The dataview I’m trying to add columns to is also just a LandingPage dataview so I’m unsure if that has anything to do with it.
Thank you!
Nope.
BAQ calculations happen server-side and will have no bearing on the UI.
This is possible. The LandingPage is a grumpy one to work with.
I recall a neat post from @klincecum where he added the columns server-side. Not sure if this is applicable in your situation, but give it a peek: Showing UD Field values from JobHead in Job Entry LandingPage View - #10 by klincecum
If it is…
You don’t have to do the first part, you can add the columns client (browser) side.
The issue arises when populating them. You can’t use a row-update because
it does weird stuff like wanting you to save it because it’s dirty.
The useful thing about the first part is it just shows you what’s possible.
The second part is what is really useful. You can manipulate the dataset coming down so as long as your columns match, it’ll pull in.
(Don’t try that in the smart client, as the smart client will strip your extra fields on the merge / deserialization.)
Here is a breakout of that post in a new thread.
https://www.epiusers.help/t/manipulating-the-kinetic-web-ui-from-the-backend-for-fun-and-profit/100267
Thank you all, I will look into this.
