In-Transaction Data Directive:
var tt = ttPOHeader.FirstOrDefault();
if( tt != null )
{
int poNum = tt.PONum;
foreach(var po in (
from ph in Db.POHeader.With(LockHint.UpdLock)
where ph.Company == Session.CompanyID &&
ph.PONum == poNum
select ph))
using(var scope = IceDataContext.CreateDefaultTransactionScope())
{
if( po != null )
{
po.ApprovalStatus = "P";
}
Db.Validate();
scope.Complete();
}
}
Did you test the approval form?
Pft–you expect me to test my work??
Meh–well. You’ll probably have to add some code into the approval BO to set that back to “A”, lol.
I approved the PO through PO Approval and it’s still pending. Womp.
I was hoping we didn’t have to hit it with a hammer, but looks like it works ok 
Dammit
I mean… that’s kiiiinda what a data directive is.
That’s what I was implying.
Likely just missing a field somewhere that the POApvMsg keys off of.
Maybe he could just use the “hold” feature ?
Nah–I’m just a knob. Don’t forget your conditions, folks!
Works as expected now that it’s not indefinitely trying to update to pending.
*Edit–Yes I TESTED it this time. 
Whew, that took a lot of poking with a stick! LOL
Thanks, @hmwillett for your massive help, and to everyone else who contributed. This is why I call you all Mega-Minds! 
Personally, i would simplify the code above written by @hmwillett to do the read, and then NOT do a “foreach” since there is only line record to read. Something like this:
//NEW VERSION (old version below for reference)
var ttPOHed = ttPOHeader.FirstOrDefault();
if( ttPOHed != null ){
var poHed = Db.POHeader.With(LockHint.UpdLock).where(x=>
x.Company == Session.Company &&
x.PONum == ttPOHed.PONum).FirstOrDefault();
if (poHed != null) {
using(var scope = IceDataContext.CreateDefaultTransactionScope())
{
poHed.ApprovalStatus = "P";
Db.Validate();
scope.Complete();
}
}
}
//FOR REFERENCE: here is the OLD CODE:
var tt = ttPOHeader.FirstOrDefault();
if( tt != null )
{
int poNum = tt.PONum;
foreach(var po in (
from ph in Db.POHeader.With(LockHint.UpdLock)
where ph.Company == Session.CompanyID &&
ph.PONum == poNum
select ph))
using(var scope = IceDataContext.CreateDefaultTransactionScope())
{
if( po != null )
{
po.ApprovalStatus = "P";
}
Db.Validate();
scope.Complete();
}
}
Listen here Tim… 
but… dont you agree that it is more efficient code?
Can we guarantee there is always just one record? It is of course on the PO Form,
but could this BO be called from another place with more than one record?
The way that this code was written, it first gets the SINGLE TT record, which only has ONE PO, so therefore there is only one po to read. Yes, there are other instances where there could be multiple values that need to be “foreached” but for this specific use case, there is only one.