Smiffy
23rd October 2002, 12:17
Help !

A new release of the porting set is currently being tested with our Baan installation (Baan IVc)

We are hitting problems with at least one of our function server sessions (there may be many more). One of the field ranges for the selection criteria on a form (the called session) does not pick up the default values. This means that the selection range in question is being processed as cwar.f = blank & cwar.t = blank. This results in no data being processed as the required record(s) no longer match the criteria

I have seen mention of 'ttstpdeldeflt'. Can someone give me more information on the procedure. Also, I am puzzled why Baan do not give sufficient guidance on this. Is there a simple baan patch to remedy the problem or do we have to go through the painstaking process of altering every script that we have developed that contains stpapi function server calls?

MariaC
23rd October 2002, 13:10
I know there are problems with service pack 9 or 10 where changes were made to api functionality. I'm not sure which service pack you're trying to test

Paul P
7th November 2002, 09:26
Dear all,

We haven't been able to get our API up and running in B5c as I posted in the thread:
stpapi.synchronize.dialog (http://www.baanboard.com/baanboard/showthread.php?s=&threadid=7361)

So is it OK for me to assume that porting set could play a role in making our API unworkable? We're on B5c SP7 porting set 7.1.c.03. We've installed the latest STP bug fix as I mentioned in the thread above. Anybody hear any bad news regarding our currently installed porting set, 7.1.c.03? Do you think we should install the latest porting set, 7.1.c.05?

Thank you very much

Rgds,
Paul

Smiffy
2nd December 2002, 18:49
our problem was not to do with the default values as I first thought. I looked at the wrong form!

The problem was caused by the fact that there was an attr.input = false in the code of the called session.

The function server code used an stpapi put command for this field, but that had always previously worked. The source code of the called session now takes presedence and the attr.input = false now blocks the entry of the field value. I simply had to alter the code to check if API.MODE.