During the installation, one step is to create a test company. In the installation guide, the test company is named with the same as the appendix of dump for test company given in the Installation CD.
For example, if the company dump is dump.939, then the Company is created with Name of 939 (ttaad1100m000 Maintain Companies).


So does it matter we take another name for the test company different from the Dump? :confused:

The records in the dump probably have records in many tables that are using that company number. There is a way around it by after loading the dump login to the new company and run tfgld9004m000 which allows you change the records to match the new company number that you have used.

I suggest taking the default company number first during installation. Once your installation is successful you can always create a new number you like and delete the ones you dont like. As Darren said the dump files has records that contain the company numbers. Baan names the table as t<tablename><company number>. You can always change the company numbers later with the tfgld session Darren mentioned.

Unless you really require the demo companies, you can easily skip that installation step.

We are installing another Baan product based on standard BaanIVc4
We have already installed this product and the demo company(939) based on BaanIVc4+sp8.
Now we plan to install this product again based on BaanIVc4+sp10. So we create another VRC branch, and install standard Baan IVc4 sp9+sp10, then reinstall this product. And we have installed the dump.939 in our new company 902.
Problem NOW:
1.When I login in 902, some tables in tcmcs can open and find some demo data, but open any session in Finance, come with "read row error, and error 506(table doest not exist)".
2.Open ttgld9004m000, and change the old company from 000 to 939, click "continue", also meets error "Read Row Error 506 on tfgld003902. Fatal Error: error506...."

Could you give me some advice!

PS. we run the "create runtime data dictionary" after install the dump.939. Does it matter?
:confused: :(

I thinkk we've got two issues here!

(1) The NAME of the company created from the dump does not matter.

(2) The NUMBER of the company you create does matter.

If you created company 902 from a dump of company 939, your need to run the tfgld9000 series changing the company number from 939 ("old") to 902 ("new"). You do not change company "000" to "939"!

Scott

I have solved the problem:

1.Create Runtime DD again
2.Read the Company Data from Dump again
3.Reorganize table
4.tfgld9004m000. This operation maybe fail. In our case, cause this Dump is exported based on IVc4 sp8, but now the environment has be updated to sp10. So some tables don't match corresponding ones in dump.
5.Run "Create Table" to create those tables failed to be created automatically by ttaad4227m000(Create Table from Sequential Dump).
6.Check the data in these tables to determine whether to input data first (via GTM) or run tfgld9004m000. In our case, we run tfgld9004m000 first, then input the data in application level(open corresponding sessions and input data):rolleyes: :D

I want to know does there exist any other reference or incompatible data that may result in data mess in new company(such as company 902) besides data of Company Number?:confused:

My experience has been that the demo companies are built and delivered for a specific SP. If I am trying to load a demo company, I would
1. Identify what SP level company 939 is built for.
2. Change PC for company 902 to that SP level
3. bdbpost the data into company 902. This should run without any (okay maybe a few) data dictionary not matching errors.
4. Change PC for company 902 to SP10 level
5. Create Blank tables. (Should only be ones for sp10)
6. Execute tfgld9004m000 to switch company pointers from 939 to 902.

This way you should have a clean demo company without to many data problems. The way you mentioned might cause reference errors.

Hi Nicholas,

Your comments are exactly right based on my practice.

And step 6 can be done after step 3.

But I still have a question:
I do step1, 2, 3, 4, 6 with login user of "baan" linked to 939(set in Maintain User Data), and do step 5 with login user of "baan" linked to 902(set in Maintain User Data).
In my opinion, step 5 must be done with login user of "baan" linked to 902. But how about the other operations?Do they have to be done with login user of "baan" linked to 939, how about other super users, or how about "baan " linked to other lower PC company?

I personally like to use the super user of Baan/bsp, this way you won't have permission problems.

For all the steps keep the user Baan/bsp/super user linked to company 902, thus making you change the PC for the user Baan/bsp, after the change PC for company.

If you don't have the user linked upto the proper PC while you are doing your bdbpost, you will still get Data Dictionary errors.

(Example.. The user Baan is linked to sp10, and company 902 is linked upto sp8 your data dictionaries won't be matching, so when you are doing your bdbpost it will be looking at what PC your user is linked to(sp10), but the dump will be saying sp8)

Hope this helps.

Hi Nicholas:

I explain your sentence "If you don't have the user linked upto the proper PC while you are doing your bdbpost, you will still get Data Dictionary errors. " as follows:

Before doing the bdbpost(or ttaad4227m000),following things must be made sure:
The PVRC of the destination company's PC(such as, 939 link to B40Cm600:PVRC B40 C4 m600) must be the same as PVRC of the login user's linked PC.

Do I explain it right?

That is correct...