Hello,

I hope someone can help me.

We have identified an issue where the table definitions are mismatched and we do not know how this has occurred.

An example of this is table tdsls041.

In GTM - ttaad4500 you can see fields ashs and ascs

The /baan/dict/dtdsls041 file shows fields ashs and ascs

Maintain Table Fields - ttadv4127s000 fields ashs and ascs are NOT visible.

We also know that the tiitm001 table has the same issue.

My obvious concern is how this has happened and the possibility of the apparent 'changes' being converted to the runtime causing data loss.

We know that the table defs were okay on or around 19th November. The only thing that has changed in Baan since is a change to the tssma101 table. Which as far as I know has no links to eithe rtdsls041 or tiitm001.

My questions are -

1. How could this have happened?
2. How do we resolve the issue?
3. How do we identify if any other tables have been affected?

Thanks

PJ

Hi there,

unfortunately I have no idea how this may have happened.
Anyway it seems that in the tools tables these fields have been deleted WITHOUT 'convert to runtime + reconfigure' being executed afterwards.
As the files in $BSE/dict still contain the correct informations all programs will 'see' the fields and no damage should have been done - so far(!).
The next 'convert to runtime' would delete these fields however, so it is vital to repair the tools tables (ttadv422 contains table fields).
As to the question whether more fields have 'disappeared' -
if you take a backup and then run 'convert to runtime' with bdbreconfig 'no' you should be able to identify the tables concerned in the $BSE/dict (IIRC the will be files with suffix .new).
Can you exclude that somebody (accidently?) fooled around with ttadv4120 (maintain table definitions)?

good luck

Norbert

Hello Norbert,

Thanks for your reply.

I don't think the fields were deleted accidentally and somebody ran convert to runtime without reconfig tables. If this was the case I would have seen the tables in ttadv502. I confirmed this on our test server by deleting a field in Maintain Table Defs. This table then appeared in ttadv502.

To resolve the issue I have done exactly what you said. I've added the missing fields back via Maintain Table Defs which has inserted the fields back in to ttadv422. I've then removed the amended table from ttadv502 to ensure a reconfig is not executed.

As to why this has happened will remain a mystery.

I don't think convert to runtime with reconfig set to No will give me any ".new" files. As the tables in Baan that hold data relating to objects needing a convert to runtime (ttadv500, 501, 502 and 503) are empty. Not unless this information is held elsewhere.

Cheers

PJ

Hi pjohns,

as usually I mixed up 'create RDD' and 'convert to RDD'.
Convert looks up in ttaad500 what has been changed, Create runs through all objects in your selection range.
'Create RDD' will create the .new files for every table that has been changed.
The bdbreconfig will read the existing table with the old dd-file, erase the table and rebuild it with the .new dd-file, then change the original to .old. (Something like this - absolutely not sure about the exact procedure and time of changing the filenames in the data dictionary - but absolutely sure to having understood the concept. bdbreconfig can run whithout access to the tools tables, therefore it needs two dd-files)
You made a point with your test .... so that excludes ttadv4120 from being the mischief. Have you had a look at $BSE/log/log.ttaad4100?
If you can't find it there things are mysterious .... a state that I don't like with machines .... real life is spooky enough :-)

good luck and don't do anythig without sufficent backup in the first place

Norbert