BPM - LINQ vs Object write

Epicor ERP 10
,
1

We have this BPM to inactivate our RunOut parts:

var qPart = (from qP in Db.Part
                              where qP.InActive == false && qP.RunOut == true
                              orderby qP.Company, qP.PartNum
                              select new {Part = qP}).ToList();
                  
               if (qPart != null)
               {
                      if (qPart.FirstOrDefault() != null)
                      {
                              foreach(var p in qPart)
                              {
                                    p.Part.InActive = true;
                              }
                      }
              
                }

However, we noticed that we ended up inactivating parts that had open job records as this way of updating seems to not trigger the expected validation (PartBeforeUpdate) experienced when we do the update manually in Part Entry screen or when we rewrite the code to use Erp.Contracts.BO.Part library (Update() method).

I was under the impression that updating LINQ-fed variables to do DB-writes were acceptable (not like forcing SQL Updates) as I thought it was still going through all needed validations implicitely in the back, but I guess I was wrong. Am I missing something here?

TIA

2

I’ve been under the opposite impression. You only get validations if running through the business objects. I’ve always assumed that there is no difference between a dbContext update or a straight sql update, which is why one needs extra security to do so. (Advanced BPM or extra options on functions)

2 Likes
3

Agreed with @Mark_Wonsil. You’re looking for business logic to save you and that sits at the BO layer. You’re working at the data layer below that.

FWIW, the only time I touch Db in a BPM is to get data. Even then, it’s only when I can’t get what I want from ttTables, a BAQ or adapter calls. I never write to it.

2 Likes
4

If you want the business logic to run, then you cannot write directly to the DB. The business logic is not triggered by a SQL trigger, but is done with the business object itself. In this case, you could populate a minimal number of fields (Company, Part, and Inactive) and then call Part.UpdateEXT business object and it will take care of the business logic.

1 Like