It all started with performance issue while creating a batch order (Estimation part). I end up finding that
\Classes\PmfRecycledBpMissingCostCalc_Prod\runCalculationsForBpMissingCost
was taking a long time. I debug this while select and I saw that i was browsing ProdIds that were different then the where clause should filter. So I created a job to replicate and understand. Turns out that just changing the position of the where clause change the behavior. Below, you'll see that the first "while select" will scroll thru many ProdId, and the second "while select" will only browse the specified prodId (523464). I though those 2 syntax were equal!
PmfProdCoBy pmfProdCoBy; PmfCoByProdCalcTrans pmfCoByProdCalcTrans; BOMCalcProd_PmfCoByProduct byProductCalc; while select pmfProdCoBy notexists join pmfCoByProdCalcTrans where pmfProdCoBy.ProdId == '523464' && pmfCoByProdCalcTrans.PmfIdRefCoByRecId == pmfProdCoBy.RecId { info(pmfProdCoBy.ProdId); } warning("2 where"); while select pmfProdCoBy where pmfProdCoBy.ProdId == '523464' notexists join pmfCoByProdCalcTrans where pmfCoByProdCalcTrans.PmfIdRefCoByRecId == pmfProdCoBy.RecId { info(pmfProdCoBy.ProdId); }
I don't know how this is translated to T-SQL, but from Ax point of view it looks the same. Can someone explain this?
Second question : Browsing all those ProdId, like the first while do, is this then intended purpose of runCalculationsForBpMissingCost? Because I don't see why you would browse all those prodId to Estimate only 1.
*This post is locked for comments