okneb1
1st November 2022, 15:55
Hi,

LN 10.7
Portingset:9.4f
Tools Interface Version (Bshell):2450

What I'm trying to do: Whenever a "receipt" record gets created in whinr110, I'm also trying to update CDFs on all other "issue" records in whinr110 that are related to a specific prod. order.

So, for example: A record of type "Receipt" gets created in whinr110 and is related to prod. order 1000. This record already has a CDF filled with some data. At the moment when this record gets inserted, I also want to fill this CDF on pre-existing transactions in whinr110 (type Issue) that are related to this prod. order 1000. The "issue" records already exist in table whinr110 as they are created before the receipt is confirmed.

My code in after.save in extension point for whinr110:

function extern long after.save.object(long mode)
{
| hook code
if mode = DAL_NEW then
if (trim$(whinr110.cdf_huid) <> "") and
(whinr110.koor = tckoor.act.sfc) and
(whinr110.kost = tckost.receipt) and
(trim$(whinr110.rcno) <> "") and
(trim$(whinr110.orno) <> "") then
|* WARNING: this function calls disable.table.extension()
|* to prevent recursion error
update.cdf.handling.unit.for.receipt3(whinr110.item,
whinr110.cwar, whinr110.trdt,whinr110.seqn,
whinr110.rcno, whinr110.rcln, whinr110.orno,
whinr110.ocmp, whinr110.cdf_huid)
endif
endif


And my function:

function update.cdf.handling.unit.for.receipt3(
domain tcitem i.item,
domain tccwar i.cwar,
domain tcdate i.trdt,
domain tcmcs.long i.seqn,
domain whinh.shpm i.rcno,
domain tcpono i.rcln,
domain tcorno i.orno,
domain tcncmp i.ocmp,
domain whhuid i.huid)
{
select whinr110.*
from whinr110 for update
where whinr110.ocmp = :i.ocmp
and whinr110.koor = 1 |* production order
and whinr110.orno = :i.orno
and whinr110.kost = 5 |* issue
and TRIM(whinr110.cdf_huid) = ""
order by whinr110.trdt DESC
selectdo
whinr110.cdf_huid = i.huid
disable.table.extension()
db.update(twhinr110,db.retry)
endselect
}


And this is just not working for me. With the debbuger I get into the function update.cdf.handling.unit.for.receipt3, into the selectdo statement. db.update also returns 0, everything looks ok while debbuging, but the record just doesn't get updated (CDF is not updated in DB) after the stand. process ends. No error in event log, nothing in other logs. If I ommit the disable.table.extension(), I ofcourse get the recursion error - expected error.

I've done scenarios like this multiple times already in the past: whenever a record gets inserted in table A, also update some other records in table A. I've always done this in the after.save trigger of table A. But in this case it seems whinr110 is different in this regard.

Anyone else got this experience with whinr110?

EDIT: I just did another quick test with tccom100 table (Customers), and this principle is working: whenever I insert a new customer, name gets updated to
"test999". At the same time, I update the name to "rr" on some other, pre-existing records. And it's working OK. And it's the same principle as with my first case on whinr110 - but there it's just not working


function extern long after.save.object(long mode)
{
| hook code
domain tccom.bpid i.item
i.item = tccom100.bpid

if mode = DAL_NEW then
select tccom100.*
from tccom100 for update
where tccom100.bpid = :i.item
as set with 1 rows
selectdo
tccom100.nama = "test999"
disable.table.extension ()
db.update(ttccom100,db.retry)
endselect

select tccom100.*
from tccom100 for update
where TRIM(tccom100.bpid) = "TEST1" or
TRIM(tccom100.bpid) = "TEST2"
or TRIM(tccom100.bpid) = "TEST3"
selectdo
tccom100.nama = "rr"
disable.table.extension ()
db.update(ttccom100,db.retry)
endselect
endif
return (0)
}

günther
3rd November 2022, 12:18
Hi.

I normally do it the other way round: Assign the values to CDFs in the before.save.object hook. So you don't have to select whinr110 "for update", just assign the values you like.
And: isspace(...) is better than trim$(...) <> "".

Regards
Günther

okneb1
3rd November 2022, 21:34
günther,

I'm doing it in the before.save.object for the receipt transaction, but the problem is that CDF value is not yet known when issue transactions are created.

Timeline of events:
1. Issue transactions A and B are written to whinr110. At this moment receipt is not created yet and we don't know the CDF value
2. Receipt is created and confirmed, receipt transaction C is written to whinr100. CDF value is assigned in the before.save
3. We should now also update CDF in the issue transactions A&B from step 1 which are connected to receipt through order no. (in this step select whinr100, for update is almost unavoidable)