PeterH
16th January 2005, 10:31
I've tried to create a AFS script for this session. But after the first api-call the session doesn't do anything anymore, and I've to kill it. This is te afs-script I use:

function verwerk.overige.kosten()
{
stpapi.clear("tpppc2191m000")
stpapi.put("tpppc2191m000", "tpppc291.cprj", cprj)
stpapi.put("tpppc2191m000", "tpppc291.cico", "CONVOVKN")
stpapi.put("tpppc2191m000", "tpppc291.ccco", ccco)
stpapi.put("tpppc2191m000", "tpppc291.pric", str$pric))
stpapi.put("tpppc2191m000", "tpppc291.quan", str$(1))
stpapi.put("tpppc2191m000", "tpppc291.rgdt", dte$())
stpapi.put("tpppc2191m000", "tpppc291.year", "2005")
stpapi.put("tpppc2191m000", "tpppc291.year", "1")

e = stpapi.insert("tpppc2191m000", false, recc.mess)
if e then
stpapi.save("tpppc2191m000", recc.mess)
else
rprt_send()
stpapi.recover("tpppc2191m000", recc.mess)
endif

stpapi.end.session("tpppc2191m000", recc.mess)
}

When i start the debugger i can see that execution stops at the put command. Why I don't know. I hope someone can give me an answer. Thanks in advance.

Peter

kbartelds
17th January 2005, 10:41
This is a subsession that can not be activated directly, only from a main session. The first statement of the program is wait.for.switch, so it seems to me that a handle.subproc should be used.

Regards,
Klaas

PeterH
17th January 2005, 10:45
Tried this morning to use:
stpapi.handle.subproc("tpppc2811m000", "tpppc2191m000", add/ignore/send)
But unfortunately nothing happend. :confused:

Peter.

kbartelds
18th January 2005, 12:31
Hi Peter,

Did you get any part of the session to work with afs or doesn't it work at all? Did you check baan support to see if the sessions are supported for afs?

Can you debug the calling session (ttppc2811m000) to see whether it gets in part where it calls ttppc2191m000? These sessions have a highly irregular behaviour, in tpppc2811m000 all is done in init.form section. The first subsession that is started (at least in my case) is tpppc2131m000, so that one should be killed I guess. Maybe depending on the data present, the other sessions should be killed to.

Regards,
Klaas

mark_h
18th January 2005, 17:24
The only time I had to deal with something like this I wrote my own calling program. Below is all it had in it:


before.program:
child.id = 0

|****************************** ZOOM FROM SECTION ***************************
|****************************** FORM SECTION ***************************
|****************************** CHOICE SECTION ***************************
choice.cont.process:
on.choice:
if(child.id<>0) then
kill(child.id)
endif
child.id=activate("tpptc9110m00c")
switch.to.process(child.id)
| Cannot use zoom because tpptc9110m00c is waiting for a
| switch.to.process
execute(end.program)

choice.interrupt:
before.choice:
execute(end.program)

choice.abort.program:
before.choice:
execute(end.program)

choice.end.program:
before.choice:
kill(child.id)


You might be able to use the same method. I did this because I could not control how it reacted using the Baan main session.

Mark

RaymondH
20th January 2006, 14:09
Peter,

Did you have the AFS working for this session? I'm working on a solution for the session tpppc2131m000. But I'm still getting the problem that the execution of the session stops.

mark_h
20th January 2006, 17:45
Try writing a simple little session like I did. Just have it activate tpppc2131m000 and see if this solves the control issue. We also have several sessions that writes directly into tpppc231 without any problems that I am aware of. Even though I prefer AFS sometimes other solutions are needed - not sure if that is an option for you.

RaymondH
23rd January 2006, 16:06
Mark,

Thank you for your reply.

I tried to use your solution as well. Still my own session stops when tpppc2131m000 is started, no AFS action can be activated at that moment.

The reason that I would like to use AFS for tpppc2131m000 is that it uses the default checks within this session. But I think that filling the table, will be the best 'work around'.

Thanks for your help