FrenkR
30th August 2012, 09:45
API *find* command on a session tdpur4106m000 does not work as expected. Find command on GUI works correctly.
sample code(key on search exists and is valid):
stdapi.clear("tdpur4106m000");
stdapi.put.field("tdpur4106m000", "tdpur406.orno", o.orno);
stdapi.put.field("tdpur4106m000", "tdpur406.pono", str$(o.pono));
stdapi.put.field("tdpur4106m000", "tdpur406.sqnb", str$(o.sqnb));
stdapi.put.field("tdpur4106m000", "tdpur406.rsqn", str$(o.rsqn));
ires = stdapi.find("tdpur4106m000", e.error);


ires should return 1 but it returns 2, e.error is empty.

Any idea why this primitive is not working? Is there a problem with defining a search key?
Rgds,
Frenk

mark_h
30th August 2012, 15:40
I am no expert on LN, but typically this means you did not put all of the fields that are used in the find. So if you run the session manually, hit the find button, see how many and what fields there are for the find. You might actually have to put some empty fields to get it to find the right record.

The only other thing I can think of is it might need to be a change.view versus find - as mentioned I do not know LN. There is only one other post in this forum for tdpur4106m000 and it used find also.

FrenkR
31st August 2012, 00:46
changeView works as expected :) Problem is on locating correct line inside view.

Is there any option to see which fields are included in a *GUI* search? Do I need a source code or is there any tool - log to see what is happening inside a form?

I did set an AFS log and is as follows:
LOGGING STARTED
2012-08-30
>tdpur4106m000 clear
3dll->serv (getxml)
3dll->serv (starttdpur4106m000100)
5serv<-4gl (api.child.startedtdpur4106m0003)
5serv<-4gl (init.ready)
tdpur4106m000(5)-RUNNING:
>tdpur4106m000(5) put.field:tdpur406.orno 100022632
>tdpur4106m000(5) put.field:tdpur406.pono 4
>tdpur4106m000(5) put.field:tdpur406.sqnb 3
>tdpur4106m000(5) put.field:tdpur406.rsqn 1
>tdpur4106m000 Find
3dll->serv (def.find5)
tdpur4106m000(5)-RUNNING:def.find
5serv<-4gl (def.find00)
tdpur4106m000(5)-RUNNING:
<tdpur4106m000 an other record found (2)
>tdpur4106m000 get.field:tdpur406.orno
<tdpur4106m000(5) get.field:tdpur406.orno=100022524
>tdpur4106m000 get.field:tdpur406.pono
<tdpur4106m000(5) get.field:tdpur406.pono=4
>tdpur4106m000 get.field:tdpur406.sqnb
<tdpur4106m000(5) get.field:tdpur406.sqnb=1
>tdpur4106m000 get.field:tdpur406.rsqn
<tdpur4106m000(5) get.field:tdpur406.rsqn=1
>tdpur4106m000 end.session
3dll->serv (end.program5)
tdpur4106m000(5)-RUNNING:end.program
(0)-RUNNING:end.program
5serv<-4gl (end.program0)
tdpur4106m000(5)-RUNNING:
5dll->serv (tdpur4106m000: exit(5))
3dll->serv (afsscript: exit(3))

mark_h
1st September 2012, 01:20
Not sure what you mean by a gui search - usually the primary index contains all of the fields necessary to find the correct record. Now there is one session I did where what I did was a change.view followed immediately by a find. For some reason the next set commands did not work on that session. You can try this or using the next.set(I think that is it) to scroll through record set to find the correct record.

On 4c4 the code would not necessarily help on seeing what was used in the find. This can be setup without code just using 4gl functionality.

FrenkR
2nd September 2012, 10:38
I have 4 records. Calling next.set, cursor moves to record 2, calling again next.set does not move to a next record.
So I tried previous.view, then back to next.view and then next.set works as expected. But this procedure takes almost 1 minute to finish.

Is this an AFS bug or is there a problem inside a session?

mark_h
2nd September 2012, 20:35
On my 4c4 system I have used next.set and next.view in a couple of places - only one place caused me a problem. In my case I think it was the session that was the issue - I do know enough about LN to guess. Also in my case using next.set and change.view did not take any time at all - nothing like a minute. It could very well be the session.

On that session change.view worked, but next.set did not. What did work was a change.view followed by a find. Have you tried that?