This has always been a grey area to me and normally I work my way through problems when converting/creating to RTDD.

My problem:-

I've created a new domain. I've then ran Create Runtime Data Dictionary (ttadv5210m000). When I do this I get the attached error.

So I have now gone to Convert to RTDD (ttadv5215m000) I did not get any errors but when I go back to the Create RTDD I still get the same error.

I have also ran Convert to RTDD from within the Maintain Domains session.

If I look at the $BSE/dict/ddLIVE_001/dtd.pd directory I see the following files:

-rw-rw---- 1 bsp bsp 39191 Jan 16 13:39 dtd.pd
-rw-rw---- 1 eu010330 bsp 39270 Mar 6 08:42 dtd.pd.new
-rw-rw---- 1 bsp bsp 39191 Jan 16 13:39 dtd.pd.old

My Questions:-

1. When creating new domains/table defs what is the correct procedure for convert/create to RTDD?

2. Should I run both convert and create?

3. How do I tell when a convert/create has been successful, should there not be a dxx.pd.new file in the dxx.pd directory?

:confused:


Thanks in advance

PJ

If you see a .new file, then the convert/create has not been succesfull. The best is to run a full convert, starting from the package combination where the changed domain/table def. was changed (only converts to RTDD what really needs to be converted) for all packages - since only converts what has been changed and Baan kept track of it, there's no problem of running it for all packages.

Also, since the domain/table definitions are stored by package combination, it may be possible that something from a previous package combination also needs a convert to RTDD. So sometimes, you have to go deeper and run a convert for all package combinations (starting from the first update one to clear that message)!

Best way, you can check what is missing to convert thru table ttadv501 (reconfiguration indicators) and ttadv502 (conversion parameters Table defs./domains) and run convert to what needs to be converted.

Usually, the file dtd.pd.new should not be there. It is automatically deteled after the convert to RDD.

First, check if there are application locks for tools sessions.

I think you should rename this file, do a Convert to RDD for ALL package combinations, Domanins, ALL tables, with RECONFIGURE option on. This should not take too long. I noticed that the last lime you created RDD was 45 days ago, quite old...

Then do a CREATE RDD. Now it should work and the message shoud not come up anymore.

Regards,

Thanks for your quick replies. I'll give your suggestions a go.

In answer to my questions 1 and 2 should I always first run a convert and then a create whenever creating new tables/domians etc?

Stefan you say -

I noticed that the last lime you created RDD was 45 days ago, quite old...

Do you regularly run RTDD?

Regards

Philip

When you change anything regarding to the datastructure (domains, tabledefs) in the tools tables, you should activate the changes via a CRDD.

The data structure for the application is contained in tools tables, the RDD is the runtime data like it should be active. That is for each package combination with a different derivation structure, only the highest definitions are converted to RDD.

But without further actions, there will be an inconsitency in the system. The RDD does not match with the actual data structure in the database. The RDD changes must be activated via a reconfigure tables.

When only the datadefinition is written to RDD, but the datastructure itself is not changed, then you will have a situation where error 512 (inconsistent RDD) can occur. That is why you should always reconfigure tables at the same time your RDD for the tables change.

Your .new and .old files are used in the reconfiguration process, the .old to export and the .new to import the data. When then the new is operational, the .old is removed, the .new is renamed to the standard name.

When you do a lot of changes (directly via maintain domains or maintain table definitions) or via installation of solutions, you need to CRDD often. Otherwise it is ok to do it only sometimes.