Hi!

We're trying to use two consecutives "switch.to.company" instances for update regs of different corrects companies. But second "switch.to.company" instance doesn't work!!!.
we known "tccom950._compnr = 302" instance but what happen if we use standard dll with unknowns table updates???

Note: Is runing on b40c4, SP 19.

Regards

Example:

ret = switch.to.company(301)
db.retry.point()
select tccom950.*
from tccom950 for update
where tccom950._index1 = {:tccom950.orno}
selectempty
db.insert(ttccom950,db.retry)
commit.transaction()
endselect

ret = switch.to.company(302)
db.retry.point()
select tccom950.*
from tccom950 for update
where tccom950._index1 = {:tccom950.orno}
selectempty
db.insert(ttccom950,db.retry)
commit.transaction()
endselect

Did you control company permission's for it ? User that run your code should have permission for both 301 and 302 company. Check ttaad2121m000

Good luck !

Please check the return value of ret . It could be any of the following error.


long SWITCH.TO.COMPANY( long new_compnr )
This function switch to another company and sets the internal
predefined variable 'compnr' to the value of new_compnr.

Possible return values:
-1 : company not available
-2 : no permission to change to this company
-3 : package combination does not correspond with new
company number
-4 : first day of the week does not correspond to
first day of the week of original company.
1 : ok

Hi people!

We understand your answers, but we use super users with permissions for all companies and that companies are CORRECTS at all (same vrc, ...). In fact the second "switch.to.company" function returns "1", as first one, However there is no real change of company, second update is made in first company (301).

Thanks a lot indeed, we’re waiting for your great solutions.

Bye.

For grins and giggles add "tccom950._compnr = 302" before the second insert. You might want to do this for the first insert also. OH - does the second select find records in company 302? If so I think this will work.

Hi people!!

We know this solution “tccom950._compnr = 302” if we need to insert a record. Also is not necessary if we need update a record (second select find records in company 302 without that sentence). But the great problem is if we use, inside the “selectempty” of second select, a standard “dll” with insertions of UNKNOWNS tables. We will have to change all the “dll’s” tree, coding “ppmmxxx._compnr = var.comp”. This is not logical at all.

We are thinking that is not working at all “swith.to.company” function, because the first one work perfectly also with “selectempty” (tccom950._compnr = -1) taking company 301, but the second one, inside of “selectempty”, the status is “tccom950._cmpnr = 301” SURPRISING!!!!!!

We are in contact, regards.

My apologies - I understood that you knew about it, but I did see where you stated that when you did the second insert the _compnr was still 301. I think what you will need to do is spawn a separate process for each of the companies you want to update. Something you know that will not share record buffers, which is what is causing the problem. You could use a 3gl script, a sub-session, or even launch background batch jobs. Without know exactly what the DLL's do that you are planning to call then it makes it difficult to make suggestions.

Yes , What u observed is a noted and known phenomena . It's discussed earlier on this forum. I think it's the way database driver determines company when ppmmmfff._compnr = -1 . It relates it to the user startup company unless otherwise specified by a separate statement.So the simple solution which u too know is to write ppmmmfff._compnr = company number before db.insert statement.

hi colleges!

Really here, we have got old programs with sequential “switch.to.company” sentences working perfectly on B40c4 service Pack 4. However with service pack 19 doesn’t works by the cause we are discussing.
First of all we are locking for a solution without a massive recode of scripts. Some of then standard scripts (dlls, functions).

Thanks for your fight. We are in contact.

If ur comparisions are accurate , u can approach SSA support . But in all probability , they may claim it as feature rather than bug .

Probably there is something in missing in ur findings . Just a relook by yourself or ur colleague may probably bring some hitherto-ignored-fact in ur comparisions.

I looked your code again . There may be some possible actions. I wonder something that in your script :tccom950.orno is external variable ? if it is external then
in second loop won't run properly.Please explain your mechanism more !

Good LUck !!!

Hi people!!!

SSA has informed to us to use an hidden parameter of the function "switch.to.company":
switch.to.company(301, true)... And!!!!! works

Thank you very much really by your effort!

Think still u'll need to make good changes to ur scripts .