Hi,

We have a need to move a company into a different company number.

Currently we have a company number 256 and we want to move that 356. All the data from 256 need to be in 356.

What are the steps to be followed to avoid any bad data problem because of changed company number?

We currently do that in the development by doing pre and post and run the session tfgld900xm000 to change the company number. But this program does not seem to change the company number on some of the tables.

Any suggestions are appreciated.

We are running on Baan 1Vc4 on solaris (SP5).


Thanks

Hi,

1) Create dump company 256.
- ttaad4226m000
2) Create company 356.
- ttaad1100m000
- Create tables
3) Import dump (256) into 356:
- ttaad4227m000:
- Add tables -> yes
- Omit integrity ref.. -> yes
(Without reorganize tables)

4) You must run: tfgld9004m000,
and this session must work fine.

I hope this help you,

Regards,
Mauro M.E

tfgld9000m000 is only the first session that needs to be run. In previous version it was the only session but now you need to run tfgld9000m000, tfgld9001m000, tfgld9002m000, and tfgld9003m000. There is another session called tfgld9004m000 that runs the previous four sessons. This was created because different releases only needed certain sessions run. tfgld9004m000 was created to run the required session for the release you have installed.

To verify the results of "Correct Company Number after copying Company" session(s), you may want to run ttaad4229m000 "Print References To Parent" for table tccom000 "Companies" for Company = newcompany where ncmp = fromcompany.

This will help make sure all of the company numbers were changed in all of the tables.

These are the steps you should perform. I suggest running steps 8-11 even if step 7 is OK. If you run the sessions for changing company number twice, you are sure it is all right. I hope this helps.


1.) Create the new company in Maintain Companies (ttaad1100m000)
2.) Run Create Tables (ttaad4230m000) for your new company, and leave the remaining fields open

3.) Run Create Tables from Sequential Dump (ttaad4227m000) for your new company, choosing Delete Existing Tables, Create Rows Before Index, Disable Domain Constraints, and Ignore Referential Integrity

4.) Run Reorganize Tables (ttaad4225m000) for the tables in the new company, choosing Data and Indeces (only if you use BISAM database), Reference Integrity, and Repair Reference Counter

5.) Change to the new company

6.) Initialize the parameters for the new company with tcmcs0295m000

7.) Run tfgld9004m000. If all steps have status “finished,” you’re done – if not, continue. However, if you get the message “Cannot Start Session” you must run tfgld9000 - 9003m000 separately, one at a time, in numerical order

8.) Run tccom0100m000, inserting the new company an the mandatory information (Company number, country, currency, and language)

9.) Run tfgld0100m000, deleting the old financial company and its attachments

10.) Use ttaad4100 to modify the following tables (in any order possible):

tfgld001xxx Insert new company, then delete the old

tfgld000xxx Insert new company, delete the old (if it exists here)

tfgld001xxx Delete the old company, if previously unsuccessful

tfgld003xxx Change base company to your new company and make sure Multi Company Structure is set correctly

tfgld004xxx Change Group Company to your new company

11.) Run tfgld9004m000 or tfgld9000 - 9003m000 separately, one at a time, in numerical order


Regards,

Just some notices, regarding a few steps, from a Tools point of view:

1) Do not forget to convert to runtime of course, and change your user to the correct package combination/new_company (you need it for the tfgld900xm000 sessions)

2) No need to create tables because you will run step 3 with delete existing tables on, so its useless ans saves some time.

7) Run tfgld9004m000 : this session does nothing, it calls in fact 9000 to 9003 to do the actual renumbering. Since this sessions had several corrections made, make sure that you have the latest objects for them.

I would run this session after the reorganization, as step 5, and not in step 9 and then again in 11...

The only problems I'm used to see and fix is in case of a multi-finance setup (I think it's like this it's called, when a company A uses tables from another B), where table tfgld001 and tfgld004 sometimes do not get properly updated and you have to correct the entries manually, using ttaad4100).

Also in this multi-finance, in an import, import first company B and then A, reorganize at the end both, and renumber as final step, starting from B and then A.

with the ref intg, and repair ref counter on

Good posts, I appreciate that. Victor is right about the latest patch for these session which does a commit every 500 records, I remember, and does not duplicate so many records.

At the end of the procedure, as the last step, I think it is useful to do a repairing of Referential integrity. It does not take long, if you run it with a script, for example on UNIX:

*****************************

RDS_FULL=200
SSTS_SET_ROWS=10000
export RDS_FULL SSTS_SET_ROWS
ORA_INIT=0111000
ORA_MAX_ARRAY_FETCH=200
ORA_MAX_ARRAY_INSERT=200
export ORA_INIT ORA_MAX_ARRAY_FETCH ORA_MAX_ARRAY_INSERT

echo Start repairing referential integrity at `date` > logrefint

/baan/bse/bin/refint6.1 -p B4Cc4nll -I tablistrefint -r -l -a -b -E ref_errors -C 150

echo End of repairing referential integrity at `date` >> logrefint

********************************

Moreover, it takes less if you write:

refint6.1 -p B4Cc4nll -I tablistrefint -r -l -E ref_errors -C 150

*******************************

But let's discuss about what says the "Baan Quick Guide 1027" about the tfgld900Xm000 series programs. It is available on Baan Support Site. What do you think?

Here it is the last part of this document:


Frequently Asked Questions

Q. If I have a multi-site setup, whether it be multi-financial/single logistic, single financial/multi-logistic, etc. Can I still run tfgld9004m000 (and/or it’s component sessions)?

A. No, it is not possible to run tfgld9004m000 and the other tfgld900xm000 sessions with this setup. All companies will have to be changed back to single-financial, single-logistic companies. This means removing logical links to other companies. When this is done, then tfgld9004m000 can be run on the companies (one at a time, of course). If a company contains records with several company numbers (depending on your multi-site setup) then tfgld9004m000 can be run on the same company for several old company numbers. The session will have to be run once for every old company number. Then, after all this is done, re-establish your logical links through Maintain Logical Tables.

END OF QUICK GUIDE


I am looking forward to your reaction,

Has anybody seen a program/sql which does whole thing in Oracle-level?
I have heard rumours that somebody in Baan development has created such...

I heard about these things but I do not trust them. The reason is that there are tables in Baan, like integration tables, which contain a key , a field of type string, which contains the company number. So I do not believe that the scripts that use Oracle Tools are able to do the right change inside these stings... It can do it right only for the fields which have the domain tcncmp.

For level 1 database driver, I think it is out of the question.

I have written a program (in C), called "mapco". This can change multiple company numbers in one pass on a binary export dump. Very useful, and works as a filter, as in:

bdbpre6.1 -Itbl.lst -C100 | mapco 100=200 101=201 | bdbpost6.1 -kmnif -c 200

(Simplified command line example; exporting company 100, mapping 100 to 200 and 101 to 201 and importing into 200)

It is true about some tables store company numbers in concatenated fields. In practice the tfgld9004m000 sessions miss tables since they have to be manually updated for any table updates/additions. So there really is no good/optimal solution.

In Baan 5, the solution is to dump the company to a flat, character delimited file (i.e. bdbpre6.1 -t\| -odir ...) and then run a session to map company numbers. This session only processes domain tcncmp and will not process concantenated fields since it is a generic solution.

My mapco program does additional domains that are needed, including those in the tg package. It also allows you to specify custom domains you might add. Advantage to these solutions (including Baan 5's but it is limited) is that the programs look at the dictionary, so all table changes are automatically included.

Another advantage is that it does put a heavy load on the db server -- tfgld900xm000 had to often insert and drop all kinds of extra rows due to the integrity constraints.

My program is a little better than Baan 5's in that it can work as a filter and does not require dumping separate sequential files and with risk of choosing a character that might have been used in some table field (like "|" in the EDI tables).

This is almost as good as doing it directly in oracle, or better since you may still have to use bdbpre/bdbpost to build the new company. But, mapco supports any db platform since it runs on the export flat file....much faster too, discounting the pre/post steps.

We have customers that use my example above and also those who transfer directly from one server to another, using rsh (with some helper scripts). That is, export, map, transfer, import all in one pass; no intermediate files. They in effect refresh a test server from production data but at the same time convert company numbers...they didn't want users to mistakenly login to the test server and assume they were on production. This is done at night, in batch; can be done directly from cron -- the helper scripts, in this case, also connect to Oracle to get the full table list.

If interested, contact me (kevin.brock@fullscope.com). Helper scripts can be provided as well, though they are usually customized for a specific customer. I use these methods internally ALL the time -- we run quite a few companies and servers, being a Baan consulting and development partner.

Note: mapco has been ported to Windows. I have even run it on my notebook since it does not have to be run on a server with Baan installed.

Here's an update to my previous reply.

I got to thinking about the integration tables and went looking for others with the same issue (company number embeded in a field). In addition these two tables -- tfgld410 and tfgld418 -- only use these special field to ensure that indexes 2 and 3 are kept unique. Thus, the data is not really important; date and time are also part of this. I suppose, in theory, it might cause a problem if you had to reintegrate transactions for a previous point in time. Baan 5 does a similar thing with these two tables, but there is no solution to fixup the company numbers in the new copy company session.

Anyway, I updated my mapco program so it can be more easily configured (without source code) and it also supports these types of fields.

As for multisite, this method solves those nasty problems -- one can copy a set of multisite companies in one pass. There is no need to change them back to single/single. The tfgld9xxx sessions would only deal with one company at a time, that was why it wouldn't work. When working with the flat files without referential constraints, there is no need to worry about getting the right parent records inserted and old ones deleted.

Even so, after converting the company numbers and reloading the database it would still be good to do a refint check.

Not sure if it has already been addressed, or if anyone has experienced it but, I have learned not to trust the tfgld9004m000 session when it comes to transaction data. It seems to work fine with master data, but I have noticed some strange things in IVc. Like duplicate transactions, one with the old baanco and one with the new, or transactions that simply did not get converted to the new number. Has anyone else seen this happen?

You are right that this may happen. That is why Victor said :
"make sure that you have the latest objects for sessions tfgld900Xm000". At Baan IV c4 SP7 I did not notice these strage things anymore.

These sessions had some bugs in the past. They are not perfect now, either. That's why you must run these sessions TWICE !!!
(Read previous posts carefully)

been busy, here, only responded to last post, I wish we could be on sp7 but we are frozen on sp3 and live with the bugs that come with it. should have read before posting I suppose, need more hours in the day.

The solutions for these sessions are not so many and they have as prerequisites only the patches of the same sessions. So, if you scan all solutions, up to date, and install only the ones regarding these sessions, it will not affect your system.

I have seen errors like yours at SP4.

Advice: Install these patches, individually.