One of our developers modified a table and added a field in between the existing field. This gave rise to error 512 - Corrupted DD for the users.

I found this entry in the $BSE/log/log.reconfig

1. What does the * under the D column indicate?

2. The old number of rows is 600 and new is blank? What does that mean? Is there any data loss?

Thanks!

the * under the D means that it is making dump of and then deleting the table. tha fact that new is blank is not encouraging and probably indicates data loss. however, all might not be lost... I believe there is a way to recover the table from the dump that was made (after the table is returned to its previous definition). I'll have to do some looking for the exact procedure...

as the data definition was changed and some of the users "tried" to acess the table (without the runtime being created) - there is absolutley a loss of data.

If the R.<tablename> file still exists with the 600 rows, it should be possible to use bdbreconfig with + option (make a backup copy of R. file first) to get the data back. Depending on DD change you may have to switch the DD at the Unix level to get the "old" data to load.

Here is more info from the BaaN Support site -


when we do the create runtime (ttadv5210m000) for domains and tables we get the black terminal emulator with the information of what is being processed. This information can also be found in the $BSE/log/log.reconfig.

What does the * under the column D indicate ? Also do the Old/New is the count of the number of columns?

Is there a way we can get information if there was any data loss or not ?

If there is any data loss how can we get back the old data?

Please clarify.

SOLUTION DESCRIPTION:
Table D Old New Messages
----------- - -------- -------- ----------------------
tccom000902 *  1  1 Adding indexes ... done.

The above is one of the line from the log.reconfig file.
First column -- Table stands for "name of the table being reconfigured.
2nd column D is for data. * indicates all the records in the data.
Old -- number of records exported using old DD of the table.
New -- No. of records reconfigured/imported using new DD of the table.

Message: is for the any messages ex. No of indexs created, or any error message.
Ex. you may get # 512, index not present etc..

The procedure for the bdbreconfig file is as below.
First it exports the table into a flat file in $BSE/tmp directory using old DD of the table. The flat file name is
R. After completing exporting the table, it drops the tables and re-creates the table using new DD . Then it imports from the data from the Flat file it exported in the step 1.

If there any problem in importing table, it leaves the R in $BSE/tmp directory. You can always post the data from the R file. Also updates log.bdbreconfig6.2 and log.reconfig file with the error message.

The following instructions tell you how to solve a mismatch between your Baan table definition and your Oracle table definition. In this case you should usually get error 512 (Corrupted data dictionary) or 914 in Oracle. In other words, when you have a dd file with the .new extension, you need to follow these steps. I would strongly suggest to follow these steps in case you get error 512, otherwise, please call us to find the right solution for you.

In case you only want to reconfigure the table, just perform step number 8.
1. Open a Unix session (telnet, reflection, etc) and login as a valid baan user (e.g. bsp). It is recommendable that this user is in the same package combination as the company that has this problem.

2. Make sure you have all your environment variables set: BSE, BSE_TMP, PATH ($BSE/bin should be part of it), ORACLE_SID (must be pointing to the right instance)

3. Change directory to the one where the table definitions are located at. You can find this out by running the explode6.2 command (e.g. explode6.2 dtitm001)

4. Make a backup copy of all the dd files related to this table (current one, .old and .new)
5. Copy the current one to .new
6. Find out what fields are present in the current data definition in Baan and are not present in Oracle (you need to login to SQL Plus, then run the "desc" command for that specific table to display the fields. Then compare those fields with the ones included in your dd file from Baan).

7. Remove those fields from the current Baan data definition file using vi. There shouldn't be any reference to these fields in the data definition file. Make sure that you also check the "RELA", "REFC" and "AUDT" sections at the end of the data definition file. After you remove all the references to these fields, save this file and exit out from vi.

At this point you should be able to access the table in Baan without the error 512.
8. Run the following command in order to reconfigure the table and add the fields that were not present in Oracle.
From the Unix command prompt: bdbreconfig6.2 -mnf -N<table_name> -p<package_combination> -C<company_number>
For example: bdbreconfig6.2 -mnf -Ntiitm001 -pB50cprod -C050
9. Copy the .new file to the current one (when you run bdbreconfig manually, the .new file is not renamed automatically to the current one).

10. Repeat steps 4-9 for every table that has the 512 error.

Baanboozeled,

Those options do not always work and sometimes when the process is interrupted the bdbreconfig was causing corruption in the R data file.

We have a case with BaaN Support -

tt7.3a.02
The table tmfoc501 is 1.2 gb. Had a system crash during bdbreconfig. Now trying to recover it. Here is the error message.
>bdbreconfig6.2 -Nfmfoc501200+
Table D Old New Messages
----------- - -------- -------- ----------------------
fmfoc501200 dump file already exists (./R.fmfoc501200), not
allowed to overwite

There is a new flag -R which can be used as -
-R option is used to reconfigure a table.
For example when a bdbreconfig fails you can run the command
bdbreconfig6.x -R -n -f -N ppmmmnnn+

NPRao-
Thanks! Too bad I can not use your suggestion!
We are doomed to use the bdbreconfig6.1 that is notoriously buggy until (ha!) our management decides to upgrade the porting set!!!!!
:(
bb