Our employee table (tccom001) is created in 6 companies. It cannot be shared across all because of other business reasons. So, when someone creates a new employee, they have to perform the same function 6 times.

I wrote a custom session linked off the maintain employee session that allows you to insert the other companies you want to create the employee.

Starting in company 100, the employee (100123) is created, saved, and all is good. Then you open this session which displays employee 100123 and you set to update/insert company 310, 320, 330, 340. Refer to screen shot.

And here is the abridged version of the code:

function read.main()
{
result = switch.to.company(base.comp)
fill.current.employee() |Fills variables with employee table field values
x = 1
while x < 99 and comp.t(x) <> 0 |Loop thru each desired company
update.employee.record()
x = x + 1
endwhile
}

function update.employee.record()
{
result = switch.to.company(comp.t(x))

db.retry.point()
select tccom001.*
from tccom001 for update
where tccom001.emno = :emno.t | current employee
selectdo
assign.table.fields.from.variables()
result = db.update(ttccom001,db.retry)
selectempty
assign.table.fields.from.variables()
result = db.insert(ttccom001,db.retry)
endselect
commit.transaction()
}


I realize it's redundant going though company 100. But I do a switch.to.company and 310 should be the next company to evaluate. It determines there is no record in 310 so it will perform a db.insert. The result of the db.insert is 100 (duplicate record). I do not understand why......??

I seem to recall a thread about record buffers and switching to multiple companies. I will try to search for it. Have you tried setting the company number before the insert? Using tccom001._compnr = some company number. I am not sure if that was the answer or not.

Setting tccom001._compnr = {company} right before performing the insert DID work. While debugging, this value always had the original company number and never changed even though i used switch.to.company. I never had used this command in the past, but i don't recall performing inserts in any other company than the original.

Thanks alot!

Glad it worked I could not find the thread. I think this was one field mentioned and there were a couple of other hidden fields - maybe something like _locked or elocked, I really can not recall. This is just something I do not have to worry about - I only read from a simulation company.

While debugging, this value always had the original company number and never changed even though i used switch.to.company. I never had used this command in the past, but i don't recall performing inserts in any other company than the original.
result = switch.to.company(comp.t(x))
Tim, in your code you were never checking the return value of 'result' if it could successfully change or not. When the result <> 1, then you are still in the original company and inserting there again will cause error - 100 duplicate value.

Refer to the programmer's manual for more info: switch.to.company() (http://www.baanboard.com/programmers_manual_baanerp_help_functions_company_operations_switch_to_company)
Setting tccom001._compnr = {company} right before performing the insert DID work.
This will work as long as the table definitions of the Package Combination's/VRCs linked to the companies are same.

NPRao - Prior to setting the tccom001._compnr value; I checked the return result each time for switch.to.company and it always returned 1. That's why I was so confused because my select statement worked correctly while i was in the 'switched' company. Just when it got to the db.insert is when it didn't work as I expected.