Hi,

I have a big problem with the function switch.to.company and AFS.

We build up a connector between our EDM System ProfiDB and our Baan system (IVc4 SP 14). Item and BOM information from the EDM System will be automatically transferd (via ASCII files) to Baan. On the Baan side main parts in the session are done using AFS. This is working very well.

The only problem is that we have two companies in Baan (company A and company B). Depending on two fields in the ASCII files the data must be inserted in company A or in company B or into both companies.
The last option is the problem. The Baan session is running in company A. If now the data must be inserted into both companies the session first insert the data in company A and in a second loop insert the data in company B.

To do this I use the function switch.to.company before calling the AFS functions.

function create.edmitm(domain tccomp comp)
{
if get.compnr() <> comp then
ret.sw = switch.to.company(comp)
endif

stpapi.put.field("tiedm0110m000", "tiedm010.eitm", in.item)
....
....
ret = stpapi.insert("tiedm0110m000", 1, error.mess)
....
stpapi.end.session("tiedm0110m000")


switch.to.company returns 1 (o.k) but stpapi.insert returns 0 (failed) with error.mess "Record already exists" for insert the data into company B.

The error does not occur if the data needs olny be inserted into company B and the session is running in company A. So the switch.to.company itself is working. The error only occur if the data needs to be inserted into both companies in one run.

After hours of debugging and checking (e.g. AFS.LOG) now I am helpless.

In some other threads regarding AFS and switch.to.company I found nothing what can be the problem. Normally it must work.

Maybe someone out there knows more or has the same problems in the past?

Regards,
Juergen

Just something to try - add a suspend(x) after the last session. Try something like 3000 milliseconds. I know on some of my sessions if I do not pause things and let them clear out then I have problems when continuing. I do not have a clue if this is even remotely possible in your case, but something to try. And yes 3000 is rather a long pause, but if it works you can always try lower values. Again just something to try.

Mark

Hello Mark,

I tried your suggestion, but with no success. The problem must be in this area. Maybe the session which is called thru AFS will not closed complete or some internal pointers are not resetting.
Nevertheless thank`s for the tip.

The Problem is that we must go live with the Connector between EDM and Baan in the next time. If there is no solution for the problem I have to redesign the Baan part. Means to kick off AFS and doing it in the old way. :(

Thanks again,
Juergen

Just a possible solution: create 3 sessions. First one to read the ascii file, second one to control data for company A and third one to control data for company B. Second and third session will have the same source code and will contain the afs code to send data to edm tables.

The first session reads the file and analyses the data and will use a zoom.to to the second and/or third session to fill in the data in company A/B. The data from the file that is used to fill edm can be exported/imported, so is the requiered company number.

Regards,
Klaas

Thanks Klaas,

good idea. Need some additional coding but if I don`t find an easier solution for the problem in the next days I will give it a try. Splitting it into itself closed tasks can be the solution.

Regards,
Juergen

Just an idea if you are using jobs for the import: Split it into 2 jobs. One for Company A and one for Company B. Then the second job has to wait until the first job has ended. So you have 2 "clean" environments.

Regards
csecgn

Just FYI, I had a problem when running a batch job and using the switch.to.company with a bunch of old (ancient) db.* statements. So, it's not just afs, I think it has to do with the processing shell. We could switch once, but not back and forth very well. Our solution was to spawn another process for different companies as well, and that took care of it.

Lisa,
Db statements work properly if u use _compnr in SQL conditions for db.update / delete .For inserting records writing ppmmm999._compnr = ??? before db.insert works.

I had worked quite sometime back on this and it worked . Maybe u have a different set of objects or scenario .

Thanks Hitesh, undoubtedly you are right. Our problem was that we had 'straight lined' the Baan session code, and that did not use the comany number in the db's. We could add them, but kept running into problems on every db. To complicate, it was a finance session and which company to read for in a multi logistic / single finance setup was not so easy. The quickest solution was to start new processes. My point was just that the shells themself have a problem with it, without special handling on each db, when called from afs or not. The Baan sessions have no issue, they restart each time called. Our batch processes calls of those standard sessions expose the issues.

Completely agree with u. Especially in a complex scenario like multi-company setup with logical tables with lot of other issues , this is the best strategy.

Wrt shells having problems , I have also noticed this at times.Think Marks idea of using suspend(x) is worth testing. However this too is tested . So currently agree with the workarounds suggested by others and also if possible to get the help from SSA support on this.

The problem with the function switch.to.company is solved from the Baan Support.

Troublemakers in our case was the tools objects ottstpapihand and ottstpstandard. After installing a new set of tools components now the session works without problems.

Thanks to all for their help and proposals.

Regards,
Juergen

Hi! Please, can you tell me the solution number you used in order to solve this? I have the same problem... :( Thanks!

Hi,

the solution number is 147361.

Regards,
Juergen