Although often using following sessions:
convert to RDD
create RDD
reorganize tables
But don't know the relationships between them. And what are they doing in system, I mean physical or logistic?

Could anyone explain?
:rolleyes: :rolleyes:

Hi,

When you do create runtime DD or convert to runtime DD, the tables are actually created /modified at the database level .


Ayoobi

Amy,


By running a conversion to runtime data dictionary (ttadv5215m000) all changed software components are being converted to runtime. The tabledefinitions will be created in the range of Package Combinations you enter in the form. Note that the actual tables are not created!
Creating a runtime data dictionary (RDD) means a conversion of all in the PC's specified software components, including those that have not been changed. Thus, the following components will be converted to runtime: table definitions, domains, enum descriptions and sessions. (To create runtime for forms and menus, use ttadv5214m000.)
After running this session, your data dictionary will be renewed. This means that the directory ${BSE}/dict/<package combination> is renamed to ${BSE}/dict/<package combination.old> and the new ${BSE}?dict/<package combination> has taken its place. All companies linked to the specified PC's will be working with the newly created DD now and can (hopelfully) benefit from the changes in software.
The session "Reorganize tables" has two main options:
1. Rebuild data and indices: The data will be temporarily stored in a sequential file. Then the data and indices will be rebuilt. This option is useful for tables on which many delete actions are done. (Internally, the -Z option of bdbreconfig6.1 is executed.)
2. Rebuild and check referential integrity: A table field may have reference to another table. For example, the field Supplier in the item table refers to the Suppliers table. If you try to delete a supplier, the system checks whether the supplier is used in other tables. This is done by checking the reference counter for that supplier. If the reference counter is zero, the record is not used anymore and can be deleted. In this session, it is possible to repair these reference counters, to check referential integrity and to nullify undefined references.


All this can also be found in the session help, by the way :D . So, when you're using ASCII, start session and press "?". When using GUI, start session and press "F1" (or through taskbar: option "Help", then "Using Session"). Here is also specified when theses sessions need to be run.

I hope this clarified some of your questions. Good luck!


Henk.

Hi,

There are 2 kinds of dictionary’s in Baan. The application datadictionary and the run-time datadictionary. The application datadictionary contains all data definitions and software components. Together, these data definitions and software components form the BAAN application. The run-time data dictionary holds the translated versions of these components which are reabable for the bshell. The run-time datadictionary is created from the application datadictionary.

1> Convert to Run-time data dictionary.
This session is used to convert the changes that were made to sessions, domains, enum descriptions, table definitions, and software components directly to the run-time data dictionary.

2> Create Run-time data dictionary.
This session has the same effect as the convert to run-time data dictionary. The only difference is that it also converts not changed software components to the run-time datadictionary. This session is automatically called when creating or changing an Package Combination.

Viral.

Hi Henk,

Your clarification is good.But I am a little confused about what you said "Internally, the -Z option of bdbreconfig6.1 is executed."
Could you explain it in more detail

Amy,

The bdbreconfig-file is the tool in the portingset that is used to reconfigure the tables. So, when you fill the field "Reconfigure Tables" with "Yes", this function is ran. (This file can be found in ${BSE}/bin.) That's what is meant by "Internally...".


Henk.

There is this "Need for RDD" issue that has not been addressed.

One of the very nice concepts within Baan is the possibility to have components in different versions on your system (generations or Version-Release-Customer), that are related (derived).

Everyone knows the problem with dll's in the c:\windows\system directory. Different applications can put different versions of the same dll in that directory, without a good version handling mechanism. Solve problem by installing a newer version of the dll...

On Baan there is this derivation structure, where components can exist on various levels at the same time. A table definition can be in a c1 layer, modified on c4, also in the update standard, customized in a customisation layer. Within Baan it is possible to actually use these different versions, using different package combinations: one with customisations (typically the OPER), one with the Update Standard version, one the standard version.

This is not only true for table definitions, but also for labels, scripts, forms, menus etc.

Without a RDD, this means that starting Baan and projecting a session would result in a huge number of queries to be performed in the database. A form can contain different labels that need to be found in different VRC's, a session can in itself contain different forms each from a different VRC. If the session is started from the menu, the menu can depend on the package combination for which it is started.

This is all dependent on what data the user has stored (especially package combination) where per package combination for each of the components a different search path is defined.

All is the same with RDD, but there is a huge difference in the way this data is stored. In the process of creating (or regenerating) RDD information all these tables are queried, and the information is stored in plain ASCII text files (such as $BSE/lib/fd<OPER> for the derivation structure, $BSE/lib/user/u<user> for user settings, but also $BSE/application/<package VRC>/m<package_module>/m<code> for menus, same for forms). Plain ASCII files are read much faster than querying a database.

Then there is this specific part of the data that is needed to determine the way the data is stored in the database in the first place. These are the $BSE/../dict/ and $BSE/tools/dd files. They determine the data-construction in terms of tables and table field (and intermediate relations). An other term is the "data model". You can imagine this part being even more important when it comes to speed up things. Imagine (if technically possible) that all stored data could only be accessed after you first determined in the database via what structure the data is stored, each time you need to store something in the database.

The other type of RDD is in the database, where specific information from a lot of different tables is stored into a single record instead. The table ttadv999000 is an example for this. Here session information is stored. Without information about the session in this table, a session does not run.

So instead of huge performance consuming (*) queries at the session start, a read of a few ASCII files and some limited database queries are sufficient to start a session.

(*) There is this loading and initializing of specific bshell memory where a copy is made from the shared memory and a caching of all the used component that can take a significant amount of time at session start.

One thing to add still (this is really an exhaustive thread!)

So why do we need to reconfigure tables after a convert to runtime?:

Imagine you are adding a new field to a table. As it has been said above, during runtime conversion this data format of a table is stored as an ASCII file. So, the next time you start Baan, it will expect to find that new field it the records when it retreives values from that table.

However, on the database level, the convert to runtime session does nothing at all. In the database, that new field is still missing. And that is where the "reorganize tables" comes in: The data stored in the database table will be "dumped" temporarily to an ASCII file, than the table will be dropped from the database (physically deleted) and re-created with the new data format. So, at this moment, the table get's it's new field physically. After that, the data is reloaded from the ASCII file to the new table (with the new field getting it's default
value from the runtime data dictionary).

Uli

Hi OmeLuuk

So the "Convert RDD" only update corresponding ASCII files for the changed components, or doed it also update data(records) in relevant tables, such as ttadv999000 in the database?

.Rebuild DD
After construct one PACC(xxx), and run the "Rebuild DD", what will Baan do logistically and physically?The following is my opinion:
1.
If this is the first time run "Rebuild DD", system will first create folder under $BSE/../dict for this PACC(xxx);

2. under this folder
If first time, Create ASCII files for all tables and domains definition
If not first time, system will first rename all existing ASCII files: ...+.old; and create new ASCII files for all tables and domains definition

Create Runtime DD
Could anybody list the operations that system do in this Create DD, like 1....;2....? :confused:

Amy,

In any case it is more safe to run "Create RDD" rather than "Convert to RDD" beacuse convertion sometimes ignores some changes becuase some values in 000 company may not correspond the actual situation. It takes more time but it provides the necessary result. Be sure that the bshell is 'closed' while RDD is created (the current package combination and companies attached to it). All package combination RDDs derived from current should be recreated.

Hi Vens,
Your reply makes more sense.But I am not so clear about some points or opinions in the replay:
1.
***************
convertion sometimes ignores some changes becuase some values in 000 company may not correspond the actual situation
***************
So would you give some examples for " sometimes " and "some values"?

2.
***************
bshell is 'closed'
***************
Could you explain more detailed?

3.
***************
All package combination RDDs derived from current should be recreated
***************
Why must I do this for the derived PACC, I mean, what does the system do background for this RDD for derived PACC?:confused:

Hi Amy,

- Sometimes means that baan also has some bugs. I have encountered several times that Convert to RDD did not do anything although i had changed my data - f.e. installed new solution via PMC. It happens because semaphore field in 000 company doesn't change. (i dont remeber what table exactly). e.g. baan does not know that convertion is needed. running Create RDD makes you sure.
- Child PACC - it is not also mandatory but ONLY in the case that you are sure that you didn't derived ANY defiinition (domain, table etc) from parent PACC in your customisations. If it is no difference between standart and yours it is no good to RDD your customisation.
- "Closing' bshell means making it unreachable for other users (only except the one making RDD) - preferrably bsp. in UNIX you can make it by chmod 000 $BSE/bin/bshell6.1. On the whole the other users can stiill working in other PACC if you are sure that they can not switch to PACC you you working with.

Hi Vens,

Thanks

Originally posted by chanel_amyz
So the "Convert RDD" only update corresponding ASCII files for the changed components, or doed it also update data(records) in relevant tables, such as ttadv999000 in the database?Both.

But since you notice the RDD issue takes a lot of time (all the time saving you get later, needs at least to be done once), not all is converted to RDD each time. There is a table with runtime indicators, indicating what parts of the software needs to be converted to runtime data dictionary. This is table ttaad400.

Not all changes however are recorded in this table. If you delete your RDD files on disk manually, the ttaad400 table does not know. Also after manual changes in the RDD files, the system does not know this (like in that thread about debugging, altering the package derivation structure editing the fd file).

Users should not be active in this process of rebuilding RDD, due to at least two reasons:
- Since you will alter disk files, that are read on login and cached thereafter, the new information will only be available after login.
- Change in the data model however can cause a table to be rebuilt. But when the table is in use, it cannot be locked for rebuilding and reorganisation will fail. This will cause an error 512: the RDD information does not match the actual datastructure in the database. Users that use the old RDD (cached) info after a table has been succesfully reorganized will also notice this change.

OmeLuuk,

I do not argue that rebuilding RDD takes a lot of time but sometime it is more safe simply. Having powerful server can help it. Also avoiding users from current PACC being rebuilt i think also recommend (Baan doc requires it also). Rdd with 512 error anyway needs to be recreated.
There are also several problems which are difficult to forsee beforhand. Once while running RDD the power supply failed for instance and after that we had serious problems with entire package combination.
And manually deletion anything from baan directories is just a disaster i guess. :)

Originally posted by Old Vens ...
There are also several problems which are difficult to forsee beforhand. Once while running RDD the power supply failed for instance and after that we had serious problems with entire package combination.
And manually deletion anything from baan directories is just a disaster i guess. :)I agree with you. Having a backup of the RDD directories is not a bad idea. But it is not sufficient (ttaad400, ttadv999).

About the reports / form and menu dumps: they are also converted to RDD (dumped and compiled) due to eliminating database actions when the components are needed. But the nature of these compontens is rather different. Furthermore, there may be more (for each package VRC in the derivation structure) different instances of the runtime components of this kind. Only the first one actually found via the derivation structure is used. With the newest ttstpsessinfo you can see the path where formdumps and reports are taken from. There may be RDD dumps and compilations on disk where you would not expect them (due to component VRC) because they can be dumped / compiled in other VRC's too, under certain conditions.

I hear you thinking: what conditions?

There is this option 3 in the session "Compile Reports" (ttadv3240m000) and "Create Runtime Data Dictionary (Forms and Menus)" (ttadv5214m000). Also with option 2 this is possible, but then there should at least be one used part of the report / form / menu in the higher VRC.

some useful information here:http://www.baanboard.com/baanboard/showthread.php?s=&threadid=6293

Agreed, agreed. The first initial post didn't concern Forms/Reports/Session and so on so i didn't mention such things. What about backups we use Oracle archivelog and periodically perform cold copy of all its datafiles, indices etc (shutting down the instance, copying and then restarting again).

That is the backup of the data (which is ok). But do not forget to also backup your programs ($BSE/bin; $BSE/tools and $BSE/application) too. On a restore you will also need your $BSE/lib, $BSE/<other> and your RDD.

In general, RDD information can be recreated (because it does not contain the "master data"), so a backup of this is not needed. But a `cp -p dd.old dd` happens to be so much faster...

Originally posted by chanel_amyz
some useful information here:http://www.baanboard.com/baanboard/showthread.php?s=&threadid=6293 This copy of the HELP proves again that Help is only one button away.

Hi OmeLuuk,

:) Of course we backup all important components of RDMS and Baan. it is simply difficult to describe all the situations in two or three letters. In some cases we use cp but archive logs are going to the robotic tape. In case of restore perhaps it would be "a bottleneck" to find much spare free space to place all necessary archives there.

The other moment is that we often do not know who is locking the table and the status of lock. Oracle9i has lock manager but our 8.1.7 doesn't say the lock owner. Any idea?

Old Vens,

Have you checked v$locked_object?

Hi Pat,

Yes, i did. One thing prevents this view to be as convinient as 9i. you need to check session_id in order to find out what is locked and what select statements are issued. Maybe i need to try to create something like materialized view which would automatically gather information required.

I think if you join up v$locked_object, v$session, v$sql and v$sqltext then you should be able to get what you want :)

Hi Pat,

I think you are right, it smth. like this. E.g. it would be looking like our own "Lock manager" :)