Hi
I am trying to read value from multi-occurance session with following function server coding..

domain cpitem item1
domain cpitem temp.item
domain cpcom.plvl temp.plvl

stpapi.put.field("cprpd1500m000", "cprpd100.plvl", str$(temp.plvl))
stpapi.put.field("cprpd1500m000", "cprpd100.plni", temp.item)
ret = stpapi.find("cprpd1500m000",err.mes)
stpapi.get.field("cprpd1500m000","cprpd100.plni",item1)
............


When I check the value of item1, it is not equals to temp.item.
It is showing the first record.
I dont know what I am missing here...

appreciate your help

Use stapi.change.view in forms type 3.

Then use find for a specific ocurrence on that group.

Hope this helps.

Thanks for your reply, but this session(cprpd1500m000) is of type 2. It does not have group field. The primary key consists two fields
1. plvl : plan level (type byte)
2. plni : plan item (type string)

I set these values before find using stpapi.put.field().

regards

I believe even on a multi-occurrence of type 2 you need to do a change.view. Then you can do the find. I am not positive since I do not have access to that session. Give it a try.

Good Luck!

Mark

Mark, I tried changing the view using stpapi.change.view().
This function is returning value "2", which is according to documentation 'first record in the next view'

Document fragment..
_______________________________
long stpapi.change.view(string session [, ref string err.mesg])
ARGUMENTS
session Name of the session this command is executed on.
err.mesg This parameter will contain the text of the error message if the function cannot complete normally.
DESCRIPTION
This sets the current view for sessions with forms of type 3 (multiple occurrence plus view). The field values of the view fields must be set prior to calling this function.
RETURN VALUES
0 No view found or error occurred and err.mesg is filled
1 View found (err.mesg is empty)
2 Another view found (err.mesg is empty)


EXAMPLE
stpapi.put.field("dtfsa1501m000", "dtfsa101.seno", str$(i.seno))
ret = stpapi.change.view("dtfsa1501m000", error.msg)
if not ret then
message(error.msg)
endif
Explanation:
The View field in the session is changed to the given key.
USAGE NOTES
The behavior is the same as a find/new group action through BW: if no records exist, then no record is shown (return value 0); if at least one record in the view exists, then the first record in that view is selected (return value 1); if the view cannot be found, then the first record in the next view selected (return value 2), or if there is no next group, then no records are shown (return value 0).
The error messages returned can be:
n Any error message from the session given during the browse action.
Before a record can be inserted on a type 3 form, the view must have been changed to the desired key fields.
_______________________________

I dont why it is returning value 2, when there is view defined and record exists!

When I looked at the table level, the first view (1st primary key) consists 2 fields which are plan level (plvl) and plan item( plni). I set these fields properly, but I dont know why it is not picking up that record.

I desperately need this functionality as I have to set a value, which has question attached and I need to pass answer to that question (other than default answer), which I cannot do with dal.update()

regards

You could try doing a change view and then a find.


domain cpitem item1
domain cpitem temp.item
domain cpcom.plvl temp.plvl

stpapi.put.field("cprpd1500m000", "cprpd100.plvl", str$(temp.plvl))
stpapi.put.field("cprpd1500m000", "cprpd100.plni", temp.item)
ret = stpapi.change.view("cprpd1500m000",err.mes)

stpapi.put.field("cprpd1500m000", "cprpd100.plvl", str$(temp.plvl))
stpapi.put.field("cprpd1500m000", "cprpd100.plni", temp.item)
ret = stpapi.find("cprpd1500m000",err.mes)
stpapi.get.field("cprpd1500m000","cprpd100.plni",item1)



I had to do something like this before to get it on the correct record.

Mark

Hi Mark,

I tried that but this time, the stpapi.find() is giving me value "2", which is "A record different to the one requested was found" according to documentation.

Why is this session so special, I tried same kind of programming on other (multi-occurance) sessions, they are all working fine and giving me what I want except this...

I also looked at the source code of session cprpd1500m000, it does not have any query.extends or anything like that which might tamper the starting mode of the session.

regards

Can you put the source session in debug mode and watch what happens with it? This way you can see what happens when the session is started and what happens when a change.view or find is done. This might help you solve the problem.

If that does not work then I would place a call with Baan. A new version of the session may be needed.

Mark

I might be able to help out if I had a screen print of the session. Are plvl and plni the first and only key fields of the main table?

Gordon,
I attached the screen shots of session cprpd1500m000, sort options and indices of main table (cprpd100).

Mark,
I did put the source (cprpd1501) of session cprpd1500m000 in debug and when program entered into above source, the value of cprpd100.plni (Plan Item) is not the same value which I assigned in my program, instead it is showing the first record.

I created a case with baan support, and I sent bic_info of the session as per their request.

regards

From looking at the session it looks like your original find was correct. But I am not sure because I have never seen a multi-occ session like this. There must be something(not sure what) in the session that must be resetting it to the first record. I hope Baan gets you a quick response - and please let me know what the solution is.

Sorry I was not much help.

Mark

I am also facing the same problem (different session though).
If anybody has a solution for this please post it.
Thanks.
John

I don't have access to Baan V but:

The field "Plan Item" actually looks like a combined field. It has three columns displayed under it's header. Check the table definition and if this is the case, then put() all four key fields before the find() function.

Also, I've never been able to get an API to work for a session that has a start option of Find (7). Symptoms of this happening are receiving dialog errors "Zero pointer: name '' in qss.search", "Use of NULL pointer on ''", and "Can not continue in <session> in DLL: ottstpstandard()". If this is the case, try changing to something like GetDefaults.

Best of luck,

Thanks Gordon !
I changed my option to GetDefaults and it works like a charm :)
Thx

For Segemented fields such as Item and Plan Item, U need to specify the segment number in the "stpapi.put.field" AFS Call.

Example:

stpapi.put.field("tcibd0501m000", "tcibd001.item.segment.2", "My Item")

This notation will plug the value "My Item" in Item Segment. For Plan Items, use segment.3 for Item Segement

Thanks
Krishna

Use -- -set AFSLOG=1 in the command line in order to know what values are sent to session while using AFS Calls in a script. On Unix afs.log fille is created in users Home Directory.

Hi Krishna,
Thanks for the wonderful hint!
It works with segments!!
Finally baan also came with the same solution!

Once again I thank you all for your suggestions

regards

We had the same problem. We use an outside PDM system that calls BOM create/update. I am attaching our case description and solution we offered to Baan below (apologies for size of reply but the problem lasted many months and was solved accidentally).

Case description:
We have installed standard program solution 119947 (Nov-20-2001) on our production system. It generally works OK. To solve a specific problem we installed standard program solution 121657 (Jan-17-2002) on our test system. After installing that solution 121657 one of our cc-package BOI's written by Origin began failing. When we back out the solution 121657 the BOI again works correctly.

Looking at the compiled dates on the standard programs in Unix shows that only two routines were actually updated in 121657: stpstandard and stpcreatedll. The defects in solution 121657 affecting B50b were 115419, 120512 & 120188. Specifically DF120188 in stpstandard reads " DF120188, 2002/01/11: API exec form sections during to.form" and DF120512 in
stpcreatedll reads "DF120512 Functions modified to handle optional arguments". We suspect Baan's fixing DF120188 or DF120512 caused our problem since we are dealing with API functions.

We went further in the investigation and installed standard program solution 122405 (Feb-15-2002). The problem still exists at that level and also at all previous levels of the standard programs until we get to 121253 (Jan-02-2002) where the BOI works again. For your information: solution 121253 ONLY updated stpcreatedll by fixing DF120275 and reads "DF120275
Incorrect function-names when not restarted".

Could you please advise what program (stpstandard or stpcreatedll) would affect the way a BOI would behave? We believe this is caused by the Baan solution 121657 but we do not know how to describe the problem to Baan since it is a non-standard BOI. And since the BOI calls stpapihand directly;
we believe we are one level removed from the cause of the problem, so logging input/output from our BOI would not help.

Thanks

Solution description:
Solution from the customer:

Please close this case.

The solution is to recompile our custom VRC's whenever we do a porting set upgrade. In our case we updated from 6.2a.03.03 to 7.1c.02 and the was updated from 1997 to 2001. Apparently stpapi.change.view() to sessions with a form.2 does not work in 7.1c.02 with the older in the the session script.

Note to case 938785
Further information plus afs.log
Cust Case#:
Created: Mar 30 2002 2:50AM
Note ref: 2979814

Hi Quin,
I have investigated our situation further. We have a customized script tibom1510. This was known before the case was entered. The custom code adds four fields to the form and other minor changes.

I found that my 3GL test script does work using standard (uncustomized) Baan code for script tibom1510 (VRC B50U_b_stnd). The update date on that script is May 26, 2001. So, I agree with PEG that they cannot reproduce the problem.

The plot thickens:
By empirical testing I found that if I use the tibom1510 script object from when it was last "officially" compiled (Nov 2001) my 3GL test script always FAILS. If I simply re-compile the script tibom1510 then my 3GL test script always WORKS. The bic_info6.2 is identical (except for compile date and developer ID) for the two objects. I have copied the afs.log for the two
executions below. You can see that the stapi.find() fails with the older object and works with the newer compiled object.

So, the problem appears to be what is in the older compiled object. The Nov 2001 compile was using porting set 6.2a.03.03 and the standard programs from July 2001. The compile I just did today is using porting set 7.1a.02 and the standard programs from Mar 15, 2002. There are three #includes in tibom1510:
<bic_dam>, tcmcs2000, tcmcs2010. The last two have not changed for several years. <bic_dam> changed when we updated the porting set .

I should not have to re-compile my program after a standard program update. Please continue your investigation with PEG, perhaps focusing on the new porting set being (somehow) incompatible with older compiled code for tibom1510.

Thanks
Steve

AFS.LOG:

LOGGING STARTED <--- Before re-compile
03-29-2002
269->get.fields
269<-get.fields0tibom010.mitm0tibom010.mitm.segment.11tibom010.mitm.segment.2
1tibom010.pono0tibom010.seqn0tibom010.opno1
>tibom1510m000 put.field:tibom010.mitm ZX100
>tibom1510m000 change.view
269->start.set
269<-start.set01
<tibom1510m000 1 view found
>tibom1510m000 put.field:tibom010.opno 0
>tibom1510m000 put.field:tibom010.pono 30
>tibom1510m000 put.field:tibom010.seqn 6
>tibom1510m000 Find
269->def.find
269<-def.find00
<tibom1510m000 an other record found (2) <--- failure
270->get.fields
270<-get.fields0tibom010.mitm0tibom010.mitm.segment.10tibom010.mitm.segment.2
0tibom010.pono1tibom010.seqn1tibom010.sitm.segment.11t1
269->syncmodify
269<-syncmodify0
>tibom1110s000 put.field:tibom010.exdt 1017622610
>tibom1510m000 update
270->modify.set+save
270<-modify.set+save00
<tibom1510m000
>tibom1110s000 end.session
270->end.program
270<-end.program0
>tibom1510m000 end.session
269->end.program
269<-end.program0

LOGGING STARTED <---- After re-compile
03-29-2002
291->get.fields
291<-get.fields0tibom010.mitm0tibom010.mitm.segment.11tibom010.mitm.segment.2
1tibom010.pono0tibom010.seqn0tibom010.opno1
>tibom1510m000 put.field:tibom010.mitm ZX100
>tibom1510m000 change.view
291->start.set
291<-start.set01
<tibom1510m000 1 view found
>tibom1510m000 put.field:tibom010.opno 0
>tibom1510m000 put.field:tibom010.pono 30
>tibom1510m000 put.field:tibom010.seqn 6
>tibom1510m000 Find
291->def.find
291<-def.find01
<tibom1510m000 record found (1) <---- success
292->get.fields
292<-get.fields0tibom010.mitm0tibom010.mitm.segment.10tibom010.mitm.segment.2
0tibom010.pono1tibom010.seqn1tibom010.sitm.segment.11t1
291->syncmodify
291<-syncmodify0
>tibom1110s000 put.field:tibom010.exdt 1017622986
>tibom1510m000 update
292->modify.set+save
292<-modify.set+save00
<tibom1510m000
>tibom1110s000 end.session
292->end.program
292<-end.program0
>tibom1510m000 end.session
291->end.program
291<-end.program0

=====================================================