<?xml version="1.0" encoding="utf-8"?>
<ManualTopic ID="/baanerp/tt/EnterpriseStudio/onlinemanual/data_dictionaries" xml:lang="en" TopicType="Overview">
	<Header>
		<Title xmlns:HTML="http://www.w3.org/TR/REC-html40">Data dictionaries</Title>
		<Keyword ContextSensitive="No"><Level1>
                                    Infor ERP LN Development Tools
                                 </Level1>
			<Level2>data dictionary</Level2>
		</Keyword>
		<Keyword ContextSensitive="No"><Level1>
                                    Infor ERP LN Development Tools
                                 </Level1>
			<Level2>application data dictionary</Level2>
		</Keyword>
		<Keyword ContextSensitive="No"><Level1>
                                    Infor ERP LN Development Tools
                                 </Level1>
			<Level2>runtime data dictionary</Level2>
		</Keyword>
	</Header>
	<GeneralSection><Paragraph class="Default">A data dictionary is a collection of descriptions about a data model or system.</Paragraph>
		<Paragraph class="Default">There are two unique data dictionaries: the Runtime Data Dictionary and Application Data Dictionary.</Paragraph>
		<Paragraph class="Default">This section describes the purpose of the Runtime Data Dictionary, the purpose of the Application Data Dictionary, and how you convert data from the Application Data Dictionary to the Runtime Data Dictionary.</Paragraph>
	</GeneralSection>
	<GeneralSection><SectionTitle>The Runtime Data Dictionary</SectionTitle>
		<List><ListIntro>The Runtime Data Dictionary (RTDD) refers to the files and data that are used to run the system, hence the term “runtime”. The purpose of the RTDD is two-fold:</ListIntro>
			<ListItem>Provides configuration information to the technical architecture. This is also called the runtime environment.</ListItem>
			<ListItem>Provides optimized application information when the application is running.</ListItem>
		</List>
		<GeneralSection><SectionTitle>Configuration Information</SectionTitle>
			<Paragraph class="Default">The RTDD is necessary because the system is configurable in its technical architecture. If this configuration information were stored in a database, the system would not know how to get this information, or from what database to get it. The system would not know the language to present any messages, or the programs it should start to support the system. To address these issues, information is available from the application server’s operating system during the bshell startup procedure.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Optimized Application Information</SectionTitle>
			<Paragraph class="Default">The application repeatedly requires a lot of information about the application components that are running. While this information could come from a database, because the information may be required frequently, and changes are infrequent, it is faster and more efficient to pre-process this information and store it in a compressed and optimized way. Examples of this type of information are date formats, menus, toolbar texts, menus and forms. Application components like forms, form fields, and labels are stored in a database. To gather all the information from a database when it is needed by a running system would slow down the system. Therefore, the system uses a convert function to compile this information into an optimized format.</Paragraph>
		</GeneralSection>
	</GeneralSection>
	<GeneralSection><SectionTitle>The Application Data Dictionary</SectionTitle>
		<Paragraph class="Default">While the runtime data dictionary is stored in the application server’s operating system and some Enterprise Server tables, the Application Data Dictionary (APDD) is data stored in tables. The APDD data is accessed by sessions.</Paragraph>
		<Paragraph class="Default">By having the APDD stored as data and accessible in the sessions, this allows administrators to easily administer the system using sessions, and allows developers to easily develop applications in the system. In this way, the application administration environment and application development environment are fundamentally the same as the application execution environment.</Paragraph>
		<Paragraph class="Default">The APDD data is stored in company number 000.</Paragraph>
	</GeneralSection>
	<GeneralSection><SectionTitle>Convert to Runtime Data Dictionary</SectionTitle>
		<Paragraph class="Default">After the application data dictionary data is maintained in the sessions, the information intended for the RTDD must be extracted from the APDD, reformatted or optimized and made available in the runtime data dictionary. This process is called “Convert to Runtime”.</Paragraph>
		<List><ListIntro>The optimized information is in one of these formats:</ListIntro>
			<ListItem>File on the operating system.</ListItem>
			<ListItem>Compressed data in a table.</ListItem>
		</List>
		<List><ListIntro>The categories of making the APDD available at runtime include:</ListIntro>
			<ListItem>Directly Available: A conversion step is not necessary because the system will access the data directly from the APDD.</ListItem>
			<ListItem>Convert (to Runtime): This type of conversion takes information out of the APDD, and creates files in the application server’s operating system.</ListItem>
			<ListItem>Compile or Dump: Usually performed by programmers, this type of conversion takes information out of tables and script files, and stores them in an optimized and encrypted format, called an object or component, at the operating system level.</ListItem>
		</List>
		<Paragraph class="Default">How do you know when a convert to runtime is required? This can be a difficult question. The most effective way is to see if the session has a convert to runtime button or a pull down menu item under the <GUIRef href="" role="manual">Specific</GUIRef> menu. A convert to runtime is required, for example, for Package Combinations, Tables and Domains.</Paragraph>
		<List><ListIntro>Other entities require a compile step to make the APDD information available for use. Usually, compile steps do not require signing out of the system (a change to the users start menu is a notable exception). Compilation is required, for example, for:</ListIntro>
			<ListItem>Menus</ListItem>
			<ListItem>Labels</ListItem>
			<ListItem>Sessions and Forms</ListItem>
			<ListItem>Reports</ListItem>
			<ListItem>Scripts and libraries</ListItem>
		</List>
		<GeneralSection><SectionTitle>Convert to Runtime Sessions</SectionTitle>
			<Paragraph class="Default">There is a number of Convert to Runtime sessions that is used during software development. Usually, you can initiate a convert to runtime for an entity from the <GUIRef href="" role="manual">Specific</GUIRef> menu in the session that maintains that entity.</Paragraph>
			<Paragraph class="Default">When more than one entity requires conversion, or when more than one element in an entity changes, you can use a conversion session that is accessible from the menu browser. For example:</Paragraph>
			<TABLE border="1" borderstyle="default" space-and-orientation="indented-estimated"><THEAD><TR><TD rowspan="1" colspan="1">Session</TD>
						<TD rowspan="1" colspan="1">Description</TD>
					</TR>
				</THEAD>
				<TBODY><TR><TD rowspan="1" colspan="1">Convert to Runtime Data Dictionary (ttadv5215m000)</TD>
						<TD rowspan="1" colspan="1">
							<Paragraph class="Default">The convert to runtime data dictionary in Application Development performs specific processing on the Table Definition and Domain files associated with the Package Combination. The table and domain definition files contain information about the table’s fields and data types. If this format changes, a field is added to a table and the table definition changes.</Paragraph> <Paragraph class="Default">However, the physical table that has data needs to adhere to this definition. Because of the requirement that the definition and physical table be in sync with each other, a reconfiguration process performs the changes on the physical table.</Paragraph> <Paragraph class="Default">The system knows what table definitions have changed because the table definitions session adds an indicator entry in a table called Conversion Indicators (ttadv500). When a new table definition replaces an existing table definition, the change is actually pending until a table reconfiguration process is done. A table reconfiguration process is known to the system by an entry in the Reconfiguration Indicators (ttadv501) table.</Paragraph> <Paragraph class="Default">The convert to runtime process will look at the indicators table to determine what tables to convert. This session will not convert session data.</Paragraph>
						</TD>
					</TR>
					<TR><TD rowspan="1" colspan="1">Create Runtime Data Dictionary (ttadv5210m000)</TD>
						<TD rowspan="1" colspan="1">
							<List><ListIntro>This session performs the same task as the <GUIRef href="" role="manual">Convert to Runtime Data Dictionary (ttadv5215m000)</GUIRef> session, with these notable differences:</ListIntro>
								<ListItem>The session creates table/domain definition files even if no changes have been made. Therefore, the indicator table is not checked as in the <GUIRef href="" role="manual">Convert to Runtime Data Dictionary (ttadv5215m000)</GUIRef> session.</ListItem>
								<ListItem>The session creates session entries in the runtime data dictionary table (ttadv999). This table is accessed when a session starts up.</ListItem>
							</List> <Paragraph class="Default">This session is used after changes affecting the system such as importing data dictionary. The import data dictionary function is able to import application data dictionary components, and is a way to move components from one system, such as a development server, to another server.</Paragraph>
						</TD>
					</TR>
				</TBODY>
			</TABLE>
		</GeneralSection>
	</GeneralSection>
</ManualTopic>
