Copyright: Oracle Designer Design and Generation - 9.0.4.3.11  Copyright © 1995, 2003, Oracle Corporation.             All Rights Reserved


Server Generator Help

Introduction

What is Server Generator?

Accessing Server Generator

Features added for Server Generator in 6i

Getting started

Generating a database step-by-step

Designing the database

About database design

Recording the basic database design

Enhancing the database design

Generating the database

About database generation

Preparing the database design for generation

Generating the database design

Generating the Server API

Capturing the design of an existing database

About database design capture

Capturing objects from an Oracle database

Capturing objects from another database

Capturing objects from a DDL script

Reference

Database types

Datatype conversions

Table API

Module Component API

Preferences


What is Server Generator?

Related Topics

Server Generator forms the part of the Oracle Designer toolset that enables you to build databases from design specifications held in the repository. It comprises powerful utilities to automate the creation and maintenance of the server-side components of a business system.

Server Generator comprises the following utilities:

•	Generate Database Administration Objects
Generates DDL scripts to create physical database structures. Database administrators can use the Generate Database Administration Objects utility to create a physical database

•	Generate Database from Server Model
Generates database designs recorded in the repository, i.e. server models directly on Oracle databases, other databases, and/or produces DDL scripts

•	Generate Reference Code Tables
Generate reference code tables containing allowable values recorded in the repository, i.e. directly on Oracle databases, other databases, and/or produces DDL scripts

•	Capture Design of Server Model
Extracts database definitions from existing designs on Oracle and other databases, or from DDL scripts. You can use the captured definitions (or server model) as the basis for future system development.

•	Generate Server API  (Table API and Module Component API )
Generates a PL/SQL Server API interface that client applications can call to insert, update, delete and lock data in the tables generated from your designs, and to perform queries on the tables

All these utilities may be accessed from the Design Editor. How


Accessing Server Generator

Related Topics

You can access Server Generator utilities from the Design Editor:

To	Select this menu option:
Generate DDL from server model objects Generate DDL from database administration objects	Generate→Generate Database from Server Model Generate→Generate Database Administration Objects
Generate reference code tables	Generate→Generate Reference Code Tables
Generate table API	Generate→Generate Table API
Generate module component API	Generate→Generate Module Component API
Capture a database design	Generate→Capture Design of→Server Model


Features added for Server Generator in 6i

•	Oracle8i support, including:

−	index organized tables

−	function-based indexes

−	Java in the database

−	advanced queuing

−	new for indexes: compute statistics option

−	new for Oracle object types: attribute sequencing

−	new for PL/SQL functions: deterministic clause

−	materialized views replace snapshots

•	Oracle Lite support

•	Microsoft SQL Server 7.0 support

•	Database generation:

−	new foreign key generation option

−	improved default value generation

−	separate Private Declaration property for PL/SQL Definitions

−	user defined preferences provided for generation

−	user defined preferences provided for reconcile reports

•	Database capture:

−	enhanced capture capability for relational views

−	improved default value capture

−	separate Private Declaration property for PL/SQL Definitions

−	user defined preferences provided for capture

•	Table API generation - general enhancements

•	Versioning - database generation and capture to versioned repositories

Index Organized Tables

In Oracle 8i index-organized tables can be used to store the data columns of a table within the leaf nodes of the Oracle8 B-tree index structure. This reduces overall storage requirements when most columns are indexed by storing the columns only once, rather than in both an index and a separate table. Index-organized tables also reduce access time by retrieving all columns from one location instead of two. See:

About generated index-organized tables

About captured index-organized tables

Function-based indexes

In Oracle8i indexes can now be created on functions and expressions that involve one or more columns in the table being indexed. Oracle Designer 6i  supports the design, generation and capture of function-based indexes. See:

About generated function-based indexes

About captured function-based indexes

Java in the database

Oracle Designer 6i  supports the design, generation and capture of Oracle8i Java objects, featured in Oracle8i. See: About Java schema objects in the database

Advanced queuing

Oracle Designer 6i supports the design, generation and capture of the Oracle8i advanced queuing objects, featured in Oracle8i. See About advanced queuing (AQ)

Compute statistics

Oracle Designer 6i supports the new statistic gathering option for indexes. See About generated indexes

Attribute sequencing

Oracle Designer 6i supports attribute sequencing or Oracle object types. See About captured Oracle object types

Deterministic clause

This allows the system to use a saved copy of the function’s return result (if such a copy is available). The saved copy could come from a materialized view, a function-based index, or a redundant call to the same function in the same SQL statement. See:

About generated function-based indexes

About generated materialized views

Materialized views

In Oracle8i and this release of Oracle Designer,  the term ‘materialized view’ has replaced ‘snapshot’. See About generated materialized views

Oracle Lite support

In Oracle Designer 6i  the versions of Oracle Lite (previously Personal Oracle Lite) supported have been extended. See Oracle Lite support

SQL Server support

In Oracle Designer 6i, Microsoft SQL Server V7.0 is supported. See SQL Server database support

Foreign key generation

In Oracle Designer 6i you can select whether one or both tables involved in a foreign key must be selected for generation to take place.  How

This option gives you better control over foreign key generation. At different times you may, or may not want foreign keys when generating tables without their join tables.

Default value generation and capture

When entering default values for database objects you now specify whether the default value entered is a ‘literal’ string or a ‘database function’ via a new property named Default Value Type.  If the Default Value Type property is set to ‘Literal’ and the datatype is such that literal default values require quotes, single quotes are added during DDL generation.

If the Default Value Type property is set to ‘Function’, no quotes are required.

For columns and domains, the Default Value Type property has an additional option ‘Client Function Call’. When set to ‘Client Function Call’, any default value entered is ignored during DDL generation.

For example, for a date column:

Default Value Default Value Type	01-01-2000 Literal	DEFAULT '01-01-2000'
Default Value Default Value Type	sysdate Database Function Call	DEFAULT sysdate
Default Value Default Value Type	"CalcDate()" Client Function Call	(no default generated)
The new Default Value Type property can be defined for the following database objects:

- Domains
- Columns
- Attributes of Oracle Object Types
- PL/SQL Definition Arguments
- PL/SQL Definition Program Data
- PL/SQL Definition Datastructure Items

You can also set the default value type when defining allowable values, using two new properties called Value Type and High Value Type.

During design capture the Default Value and Default Value Type properties are both captured. If the datatype of the default value is numeric, the Default Value Type property is set to ‘Literal’ when the value contains numbers only.  For example:

	Default Value	Default Value Type
COL1 NUMBER(12) DEFAULT GETNUMBER()	GETNUMBER()	Database Function Call
COL2 NUMBER DEFAULT 1234	1234	Literal
If the datatype of the default value is non-numeric (text and dates), the Default Value Type property is set to ‘Literal’ if the default value contains a properly quoted string. In this case the quotes are removed from the default value.

	Default Value	Default Value Type
COL3 VARCHAR2(240) DEFAULT USER	USER	Database Function Call
COL4 VARCHAR2(240) DEFAULT ‘Joe Bloggs’	Joe Bloggs	Literal **
**If the first or last character of the default is a blank space, quotes are added and the Default Value Type is set to Database Function Call. This ensures that blank spaces are preserved on generation:

COL5 VARCHAR2(240) DEFAULT ‘ spaces ’	‘ spaces ‘	Database Function Call
Private Declaration property

Oracle Designer 6i provides an additional property for modeling PL/SQL packages, functions, procedures and triggers called the Private Declaration property.

In previous releases, for PL/SQL package generation and capture, private declarations were placed with the BEGIN/END initialization block within the PL/SQL Block property.  Now, private declarations can be specified and captured separately. During generation, the private declarations are placed at the top of the package body.

For PL/SQL functions, procedures, cursors and triggers, private declarations were specified separately but the Package Specification property was used. In this release, the Private Declaration property must be used instead. If you are migrating data from Designer 2.1.2 or 6.0, any code defined within the Package Specification property for PL/SQL functions, procedures, cursors and triggers is automatically transferred to the new Private Declaration property. During generation, all private declarations are placed before the code defined within the PL/SQL Block property.

Note:	Although private declarations can now be entered separately using this new property, they can be entered at the top of the PL/SQL Block property if preferred. Use this method if you do not want to develop the code independently.

Preferences

Oracle Designer 6i provides a set of user defined preferences that enables greater flexibility during database generation and capture:

Capture - General

General

Generation - General

Generation - TAPI

Generation - View

Materialized Views

Oracle Object Types

PL/SQL Definitions

Reconcile Report

Tables

Views

See About Server Generator preferences

Relational views

During design capture, relational views are now broken down into declarative definitions. In previous releases views were captured as free format text only. See About captured relational views

Table API generation

The Table API helps the user to maintain complex dependencies between the tables by automatically generating the code required for this maintenance. New features include:

Table API trigger generation is now optional

New preference - Generate Date Modified and Modified By for Insertion (MODINS)

New preference - Generate Constant Suffix for Repository User Defined Error Messages (USERDM)

Version control

In Oracle Designer 6i the following database objects can be held under version control: Tables, Views, Materialized Views, PL/SQL Definitions, Domains, Sequences, Synonyms, Object Tables, Object Views, Oracle Collection Types, Oracle Object Types, Queue Tables

Database administration objects may also be versioned: Oracle Databases, Other Databases (non-Oracle), Storage Definitions.

See Support for generation from versioned repositories.


Features added to Server Generator in previous releases

There was one major release (2.1) and two interim releases (2.1.1 and 2.1.2) of the Designer Release 2 product set.

Note:	Notice the product name changed from Designer/2000 to Oracle Designer in Release 2.1.2.

Features added to Server Generator in Oracle Designer Release 6.0

Features added to Server Generator in Oracle Designer Release 2.1.2

Features added to Server Generator in Designer/2000 Release 2.1.1

Features added to Server Generator in Designer/2000 Release 2.1


 Features added to Server Generator in Oracle Designer Release 6.0

No new features were added to Server Generator in Oracle Designer Release 6.0.


 Features added to Server Generator in Oracle Designer Release 2.1.2

The following new features and enhancements were incorporated in Server Generator for Release 2.1.2 of Oracle Designer:

Automatic reconciliation

Capture database objects belonging to another schema owner

Capture preferences

Create PL/SQL Summary Usages utility

Foreign key generation option

Reference code table generation

User-specific implementations of database objects

Automatic reconciliation	In this release automatic reconciliation takes place when generating directly to an online database. There is no separate ‘Reconcile’ menu option.  About
User-specific implementations of database objects	This release enables you to define user implementations for database objects, i.e. they are tailored for a specific user.  About  • Tip: On the DB Admin tab of Design Editor, expand the Databases and Users nodes to show Schema Objects. Then use the ‘Implementation’ branches under the ‘Schema Objects’ node to define user implementations of database objects defined in the repository.
Create PL/SQL Summary Usages utility	Creation of PL/SQL summary usages is a utility that creates summary usages to record the tables and columns that are used by PL/SQL definitions.
Capture preferences	In this release there are additional capture preferences to speed up the capture process.  About
Reference code table generation	In this release, the reference code table can be generated and populated in two different ways: • with allowable values associated with a particular table, generating the table(s) automatically generates the associated reference code table  About  • with allowable values associated with a particular module, generate the reference code table  About
Foreign key generation option	In this release, you can select whether one or both of the tables involved in the foreign key must be selected for it to be generated. How
Capture other users objects	This is an option allowing you to browse and capture database objects for a user other than the user specified in the Username field.


 Features added to Server Generator in Designer/2000 Release 2.1.1

This release of Server Generator provides the following support in Designer/2000 Release 2.1.1.

Oracle8 support	This release of Server Generator provides generation and design capture support for Oracle8 features. See: About generated database objects  About captured database objects
Data warehousing support	Server Generator supports the generation of data warehouse applications designed using Designer/2000.  About


 Features added to Server Generator in Designer/2000 Release 2.1

The following new features and enhancements are incorporated in Server Generator for Release 2.1 of Designer/2000:

Database generation

Design capture (previously reverse engineering)

Distributed designs

Open database support

Server API

Storage parameters

Validation tables

Open database support	This release of Server Generator provides generation and design capture support for the following database types, via a native Oracle connection and ODBC connectivity. •  Oracle8, 7.3, 7.2, 7.1, 7.0 database  •  Personal Oracle Lite 3.0 •  Rdb (v 7.0, 6.1) •  ANSI 92 •  DB2/2 and DB2/MVS v 5.1, 4.1 •  Microsoft SQL Server (v 6.5, 6.0) •  Sybase System 11 See Database generation - summary of support Database design capture - summary of support
Database generation	Extensions to database generation include:  About  •  Generation of database objects to Oracle databases,      other databases (via ODBC) and to script files •  Generation of database creation scripts
Storage parameters	This release enables you to define different storage parameters for user objects.
Design capture	Extensions to design capture (previously reverse engineering) include:  About  •  design capture from flat files, Oracle databases and      other databases •  design capture of DBA objects •  design capture of table and index storage parameters Tip: In this release the term ‘reverse engineering’ has been replaced with ‘design capture’ and the associated menu option has changed to Generate→Capture Design of→Server Model.
Server API (Table API Module Component API)	For Oracle databases, you can generate a PL/SQL package interface from repository tables and modules, that client applications can call to perform inserts, updates, deletions and locks on database tables.  About  Database triggers are also generated to handle DML operations on tables performed outside the Server API.  About  Note: The Table API does not support relational views, or Oracle8 datatypes
Validation tables	Generation of reference code tables to provide validation for allowable values  About  Generation of code control tables to provide unique identifiers for numeric columns  About
Distributed designs	Generation of replication groups and replication objects.
Preferences removed in Release 2.1

Scope of code controls table (CCTABL)This preference is now one of several ‘General Generator’ options you can set from Design Editor.

Scope of reference codes table (DVTABL)This preference is now one of several ‘General Generator’ options you can set from Design Editor.

Hold Time on Change History Columns (WHTIME)This preference is now one of several ‘General Generator’ options you can set from Design Editor.


Generating a database step-by-step

Oracle Designer supports different approaches to database design to give you control and flexibility over the database design process. When you design a database in the repository, you can choose one of the approaches below:  About

•	Analysis - This is a top-down approach based on defining the system requirements as an entity-relationship model.

•	New Design - Use this approach to rapidly design the relational database from scratch.

−	Alternatively create a new Oracle8 object-relational database design from scratch. How

•	Design Capture - This is a bottom-up approach which extracts SQL definitions from an existing database catalog or file and produces repository definitions from the design. You can modify the design in the repository and use it to update the original database or to migrate the design to another target.

Next step?

When the database design is stable and complete, you can generate client-side applications that will access the data in your database. Use the client-side generators to create any of the following types of application:

•	Oracle Designer Form Generator

•	Oracle Designer Report Generator

•	Oracle Designer Visual Basic Generator

•	Oracle Designer Web PL/SQL Generator


Setting up a database connection

Oracle Designer enables you to connect to an online database in the following ways:

•	using Oracle Net8

Use this option to connect to an Oracle database.

•	using an ODBC driver

Use this option to connect to third-party SQL databases.

When to set up a database connection

You need to set up a database connection to connect to any database except Oracle7 database or Oracle8 database. The connection must be established before you can generate or Capture objects on other databases.

You do not need to set up an ODBC connection to generate DDL scripts.

Connecting to an Oracle database

To connect to an Oracle database, you must have installed Oracle Net8.

Connecting to a database using ODBC

To connect to a third-party database using ODBC:

•	install the ODBC driver specific to the target database platform  How

•	set up a data source to the database  How

You should obtain ODBC drivers from the appropriate RDBMS vendor.


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


Generating a database step-by-step


About Server Generator and Y2K compliance

Server Generator allows the user to develop non Y2K-compliant applications when defining dates in:

•	default values

•	derivation expressions

•	ranges

•	allowable values

The following generation rule applies to default values and allowable values for columns of scalar datatype DATE:

1. 	When SYSDATE, leave this unchanged.

2. 	When the value does not contain quotes, delimit with single quotes.

3. 	If the value contains quotes, then leave this unchanged.

In practice this means:

1. 	SYSDATE  SYSDATE

2. 	01-APR-98  ‘01-APR-98’

3. 	to_date(’01.04.98’,’DD.MM.RR’)  to_date(’01.04.98’,’DD.MM.RR’)

However, the responsibility to generate Y2K-compliance is shared between you and Server Generator when:

•	setting properties of generated objects

•	entering code


About the Server API

Related Topics

The Server Application Programming Interface (API) provides a powerful and easy-to-use PL/SQL interface that client applications can call to perform queries and DML operations on base tables in the Oracle database. You generate the Server API from table and module component definitions in the repository.

Note:	The Server API is only supported on Oracle7.3 database and above.

There are two components of the Server API:

•	Table API  About

The Table API can be called by generated Oracle Designer applications to perform inserts, updates, deletions and locks on the tables used by the application.

•	Module Component API  About

The Module Component API can be called by generated Oracle Forms applications to perform queries and DML operations on the tables used by the application.

For details about which Server API component can be called from your client applications, see When should I generate the Server API? You can also call the Server API components from your own application code.

The Server API generation process

The Server API can be generated in two parts:

•	Table API packages (known as table handlers) and triggers

•	Module Component API packages (known as module handlers).
These are used by Form modules only.

Table API table handlers are generated from the table definitions in the repository. Each table handler contains PL/SQL procedures that are called by the client application to insert, update, delete and lock rows in the table. When you generate the table handler, you can also generate Table API triggers that provide validation when a DML statement is issued against the table outside the calling application. The triggers call the Table API procedures to perform the inserts, updates, deletions and locks.

Module Component API module handlers are generated from Form module component definitions in the repository. The module handler procedures are called from generated Form blocks that are based on stored procedures or views. The form calls the query procedure to perform queries on tables from the block. Generated insert, update, delete and lock procedures call the equivalent Table API procedures to insert, update, delete and lock rows in the tables used by the form.

You can generate Table API and Module Component API packages to the following sources:

•	directly on an Oracle database

•	to a DDL script

The commands to create the packages and triggers are written to a set of script files that you can then run against the target database using SQL*Plus or SQLDBA.  About

What benefits does the Server API provide?

The Server API provides a common interface that applications can call to query, insert, update, delete and lock data in database tables. It provides the following benefits.

•	Provides a common interface that multiple client applications can call, even if they run on different platforms

•	Ensures data integrity via centrally stored business rules on the server

•	Minimizes the impact of changes to application code, if business rules change

•	Promotes code consistency and reuse

•	Reduces maintenance and upgrade costs of building application code

You can customize the functionality provided by the Server API by defining your own event code segments to execute at specified points within the generated code. This allows you to pass additional information to the Server API before a query or DML operation is performed on a table, and to pass additional information back to the calling application after the table operation is completed.  About


About the Table API

Related Topics

The Table API provides PL/SQL packages, known as table handlers, that client applications can call to perform DML operations on tables. Each table handler contains PL/SQL procedures that the application can call to:

−	insert a new row in a table

−	update a row in a table

−	delete a row in a table

−	lock a row prior to an update or delete

The Table API validates the data provided by the calling application and generates default values when appropriate before the table is modified. Before a row in a table is inserted or updated, the Table API performs the following checks:

•	validates constraints

•	validates arcs

•	validates allowable values in reference code tables

•	validates allowable values in domain tables

•	auto-generates the following column values:

−	unique and sequential values for columns that derive their values from a sequence definition

−	pre-defined default values

−	derived values

−	change history information for AutoGen Type columns such as Created by, Modified by etc.

•	converts column values to uppercase

•	maintains journaling information

•	maintains denormalized columns

When you generate table handlers, you can also generate an accompanying set of database triggers that call the table handler procedures when a DML statement is issued against the table outside the application. About

Note:	The Table API is only supported on Oracle7.3 database and above.


About Table API triggers

Related Topics

When you generate the Table API, you can also generate an accompanying set of database triggers. How

These triggers are fired when a DML statement is issued against the associated table outside the calling application. The triggers call PL/SQL procedures packaged within the table handler to validate the DML statement before the table is updated.

The following types of trigger are generated for each table definition:

•	pre-insert triggers

•	pre-update triggers

•	pre-delete triggers

These triggers ensure that the Table API validation rules are enforced for a table if an attempt is made to update the table directly. In addition, generated triggers are used to:

•	validates allowable values in reference code tables

•	validates allowable values in domain tables

•	validate foreign key constraint rules:

−	cascade update and delete

−	nullify update and delete

−	defaulted update and delete

•	validate arcs

Naming conventions for generated Table API triggers

The Table API triggers are generated using the following naming convention:

cg$<time><fired_on><level>_<table_alias or table_name>

<time>	is B (before) or A (after)

<fired_on>	is one of I (insert), U (update) or D (delete)

<level>	is one of  R (row) or S (statement)

For example, a trigger generated for a table EMPLOYEES to fire on insert before each row would be named CG$BIR_EMPLOYEES. If the table had an alias EMP, the trigger name would be CG$BIR_EMP.


About the Module Component API

Related Topics

The Module Component API provides PL/SQL packages, known as module handlers, that generated Forms can call to perform queries and DML operations on the base tables used by the application. Oracle Forms applications call the module handler to:

•	perform queries on a table

•	perform inserts, updates, deletions and locks on the base tables, via the Table API

Generated Form blocks can call the module handler procedures if the block data source is a stored procedure or a view. Data is passed to and from the module handler using a PL/SQL table of records. This offers the advantage of reducing query time and minimizing network traffic, since all records are returned in a single transaction, rather than in one transaction per record.

Note:	The Module Component API is only supported on Oracle7.3 database and above.

For more information about basing Form blocks on stored procedures and views, refer to Form Generator online documentation.


Validation checks performed by the Table API

Before a row is inserted or updated via the Table API, the following validation checks are performed.

Column values

For each column, checks are made to ensure that:

•	all mandatory columns have a value

•	values provided for columns with pre-defined allowable values exist in the reference code table or domain table

•	a value is provided for auto-generated columns, if no value is provided by the calling application

Constraints

For each constraint definition, checks are made to ensure that:

•	the primary key of the table is non-updateable

•	foreign key components have a value if the constraint is mandatory


How the Table API validates allowable values in reference code tables

Related Topics

When you define allowable values for a column or a domain in the repository, you can specify server-side validation (the default) or server/client validation via the Table API. If you specified server/client validation during design, by setting the column (or domain) property Dynamic List to Yes, generated Table API code validates values provided for the column against value held in a reference code table.  About

Before a row is inserted or updated, the value provided for the column is checked against the values held in the reference code table. If a match is found, the value is inserted or updated; otherwise an appropriate error is raised.

Note:	To ensure that the most up-to-date values are used for validation, you should generate table definitions containing allowable values and the associated reference code table before generating the Table API. You should also ensure that you generate the reference code table on the same database as the tables used by the application.


How the Table API validates domain constraints

Related Topics

When you define domain constraints for columns in the repository, you can specify server/client validation via the Table API (default). In this case, generated Table API code validates values provided for such columns against the associated domain table.  About

Before a row is inserted or updated, the value provided for the column is checked against the values held in the domain table. If a match is found, the value is inserted or updated; otherwise an appropriate error is raised.

Note:	To ensure that the most up-to-date values are used for validation, you should generate the domain table and populate it with appropriate allowable values before generating the Table API.


How the Table API maintains journal tables

When specifying that journaling information is to be recorded for a table, you also determine where to maintain the information, either via the Table API or on the client  How

The Table API can maintain journaling information when the following conditions apply:

•	the table for which journaling information is to be maintained has a non-updateable primary key

•	the table property Journal is set to Server

How the journal table is populated

When an application calls the Table API to insert, update or delete a row in a table for which journal information is to be recorded, the table handler procedures populate the journal columns with the changes made to the table rows.

•	For each row inserted in the table, an identical row is inserted into the journal table and the type of operation 'INS' is entered in the journal column.

•	For each row updated in the table, a row containing the values used to update the table are recorded in the journal table and the journal column is populated with the type of operation 'UPD'.

•	For each row deleted from the table, a row containing only the primary key columns of the deleted row are recorded in the journal table. The journal column is populated with the type of operation 'DEL'.


Column values generated automatically by the Table API

Related Topics

A column can be defined in the repository as requiring an automatically generated value. Generated table handlers can populate columns with their default value when called to insert or update a row in a table, if no value is explicitly provided by the calling application.

Values can be generated for:

•	columns with a pre-defined default value

•	columns whose values are derived from a sequence

(this can be an Oracle sequence or a code control sequence)

•	columns for which change history information is to be maintained

•	columns with a derivation expression defined

If a row is inserted or updated outside the Table API, generated pre-insert and pre-update triggers are fired that call the Table API procedures to validate the statement and to perform the insert or update.

Default values

A column can have a predefined default value, specified during database design. How

The Table API can populate columns with their default value during an insert operation, if no value is explicitly provided by the calling application. When a Table API call is made to insert a row, and the indicator variable for the column is set to FALSE, the column is populated with the default value defined for that column in the repository.

Generated pre-insert triggers are fired when an attempt is made to insert a row outside the calling application. The pre-insert trigger calls the Table API Insert procedure to perform the insert.

Values derived from a sequence

In addition to enforcing uniqueness for a column using primary key and unique key constraints, you can define sequence objects to generate unique and sequential values for numeric columns automatically. For example, you might define a sequence to generate unique values for the primary key of a table, making inserts into the table more reliable.

Unique values can be auto-generated for columns associated with a sequence provided the column has a Numeric datatype. Sequence values can be generated from one of two sources:

•	an Oracle sequence, if the target for generation is an Oracle database  About

•	a code control table, if the target for generation is another database  About

Values for numeric columns can be generated automatically on the server if the column derives its value from an Oracle sequence or a code control sequence.  About

The Table API can generate unique values for columns associated with a sequence definition when the following conditions are true:

•	the column Derivation property Server Derived is set to Yes

•	no value is explicitly provided by the calling application (that is, the indicator variable for the column is set to FALSE).

When the Table API insert procedure is called to insert a new record in the column, the next unique value is fetched from the Oracle sequence or code control table.

When you define a column in the repository that forms part of a unique or primary key, you can specify that when a record is created the column is to be populated with an autogenerated unique number that is next in the sequence within its parent. In this context, parent refers to the value entered in the other column or columns with which this column forms the unique or primary key.

For example, the primary key on the LINE_ITEMS table might be composed of two columns. The LINE_ITEM_NUMBER column is populated with the next unique number within its parent. Each time a record is created, the value entered for LINE_ITEM_NUMBER is the next unique number with respect to those other records that share the same ORDER_NUMBER as the new record. This scenario is shown below:

ORDER_NUMBER	LINE_ITEM_NUMBER
1	1
1	2
2	1
3	1
This type of autogenerated sequence is only suitable if the number of rows sharing the same parent is relatively small (e.g. tens of rows rather than hundreds or thousands of rows).

Change history columns

During database design, you can specify that change history information is to be maintained for specific columns. The Table API can maintain the following types of change history column provided that the column validation property Server Derived is set to Yes:

AutoGen Type Property	Table API procedures populate the column with:
Created By	The name of the user who inserted the row.
Date Created	The date the row was inserted.
Date Modified	The date the row was last modified. The Generate Date Modified and Modified By for Insertion (MODINS) preference determines whether this information is also maintained when a new row is inserted.
Modified By	The user who last modified the row (or inserted). The Generate Date Modified and Modified By for Insertion (MODINS) preference determines whether this information is also maintained when a new row is inserted.
Seq in Parent	The next unique number within the referenced primary key, when a new record is created.
Alternatively, the property Server Defaulted may be set to Yes. In this case, only Created By and Date Created information is maintained.

Derived values

During database design, you can specify derivation expressions for columns. If the Derivation Expression property is defined and the column validation property Server Derived is set to Yes, Table API code to populate columns with the derived value during an insert operation will be generated.


How the Table API maintains uppercase column values

Related Topics

A column can be defined in the repository as requiring uppercase values only. How

If the column property Uppercase ? is set to Yes, generated Table API code converts values supplied for the column to uppercase before the record is inserted or updated in the table.

For example, a value 'Boston' provided for the column named ‘location’ would be converted to 'BOSTON' before the record is inserted or updated in the table.

Generated pre-insert and pre-update triggers are fired if rows are inserted or updated in the column directly. These triggers call the Table API Insert and Update procedures to validate the records provided and to insert or update the row in the table.

Note:	Uppercasing is always be generated when the column property Uppercase ? is set to Yes. In this case, the column derivation property Server Derived may be set to Yes or No.


How the Table API maintains denormalized columns

When designing tables, you might decide to denormalize, or duplicate, some columns in order to improve performance. Denormalization can potentially speed up queries that involve several tables, because the queried column can be duplicated on a single table, reducing the need to perform a join.  About

The Table API will automatically generate values for a column that is denormalized, provided that the following conditions are met:

•	the column Validation property Server Derived is set to Yes

•	a foreign key constraint is defined between the denormalized tables

If a row is inserted or updated outside the Table API, pre-insert and pre-update triggers are fired that call the Table API procedures to maintain the denormalization.

Denormalization support in the Table API

A denormalized column of a table takes its values based on a base column of another table using a foreign key defined between the two tables. When the base column changes, the table API will re-populate the denormalized column with the new value of the base column.

Note:	A denormalized column cannot be populated by the user; it will always take its values from the base column


Constraint validation performed by the Table API

Most types of table and column constraint will, by default, be validated on the server. The exception to this is foreign key Nullify and Default rules, which can be validated only on the client. Additional validation can also be performed on the client to provide more immediate user feedback.

The Table API provides validation for the following types of constraint:

•	primary key constraints

•	unique key constraints

•	foreign key constraints:

−	nullify update and delete rules

−	defaulted update and delete rules

•	arcs

Generated table handlers and triggers enforce these constraints on the server when the Validate In property of the constraint is set to Server or Both.

Validation of primary key constraints

When a Table API call is made to update a record in a primary key column, the Update procedure first checks whether the primary key can be updated. A primary key can be updated if the Update? property of the primary key constraint is set to Yes. If the primary key can be updated, the record in the primary key column is updated. If the primary key cannot be updated, an error is raised and, if defined, the exception is written to an exceptions table.

A pre-update trigger is fired if an attempt is made to update a record in the primary key outside the Table API.

Validation of unique key constraints

Before a record in a unique key column is updated via the Server API, checks are made to ensure that the column can be updated and to check whether the column can contain NULL values. A unique key can be updated if the Update? property of the unique key constraint is set to Yes. The unique key column can contain NULLs if the column's Optional property is set to Yes. If the column cannot be updated, or if the column is mandatory (Optional property = No) but no value is provided, an appropriate error is issued and is written to the associated exceptions table.

A pre-update trigger is fired if an attempt is made to update a record in the unique key outside the Server API.

Validation of foreign key constraints

When a Table API call is made to update a foreign key column, checks are made to ensure that the column can be updated and to check whether a value must be provided for the column. If an error is detected, an appropriate error message is raised and is written to the associated exceptions table, if defined.

Note:	Foreign key Restricted and Cascade rules are always enforced on the server as part of the table structure.

Nullify update and delete rules

If a foreign key constraint is defined with Nullify update or delete rules, and the Validate In property of the constraint is set to Server or Both, generated pre-update and pre-delete triggers are fired to enforce these rules on the server.

Nullify on update	Before a row is updated in the parent table, a pre-update trigger is fired which sets the dependent rows in the foreign key to NULL.
Nullify on delete	Before a row is deleted from the parent table, a pre-delete trigger is fired which sets the dependent rows in the foreign key to NULL.
Defaulted update and delete rules

If a foreign key constraint is defined with Defaulted update or delete rules, and the Validate In property of the constraint is set to Server or Both, generated pre-update and pre-delete triggers are fired to enforce these rules on the server.

Default on update	Before a row is updated in the parent table, a pre-update trigger is fired to set the dependent rows to the default value.
Default on delete	Before a row is deleted from the parent table, a pre-delete trigger is fired to set the dependent rows to the default value.
Arc validation

A foreign key can be defined in the repository as being in an arc. The arc provides a way of defining mutually exclusive columns whose values depend on the existence of values in another table.

Validation of foreign key arcs is enforced by the Table API using pre-insert and pre-update triggers. Checks are made to ensure that the arc is valid, that a value is provided in at least one of the columns in the arc, and that the value provided exists in the referenced primary key column.

An error is raised if the arc definition is invalid or if any of the arc conditions are violated.


When should I generate the Server API?

Related Topics

Before generating the Table API and Module Component API, the table and module component definitions should be stable and complete.

Types of application that call the Table API	When to generate the Table API
Oracle Forms Web PL/SQL Generator	Generate table handlers (and triggers) for each table definition that will be used to generate the physical tables used by your application: • When table definitions, sequence definitions etc. are complete. • Before generating module components of the types listed (left) that are based on the table definitions, and if they permit insert, update or delete operations on the tables. • If you change table definitions, sequence definitions etc. after generating the Table API. • If you customize the Table API by defining your own event code segments.
Types of application that call the Module Component API	When to generate the Module Component API
Oracle Forms only	Generate a module handler for each Form module component based on a stored procedure or a view: • After module component definitions are completed. • After generating the Table API for the tables that will be used by your application. • Before generating Form module components that are based on a stored procedure or view. • If you change the module component definitions after generating the Module Component API. • If you customize the Module Component API by defining your own event code segments.


Generating the Server API

Related Topics  Where am I?

You generate the Server API from table and module component definitions in the repository. Before generating the Server API, the table and module component definitions must be stable and complete.  For details about when to generate the Server API components, see When should I generate the Server API?

To generate the Server API:

1.	Generate all the database objects that will be used by your generated application, e.g. table definitions, sequence definitions, reference code tables, code control tables, domain tables etc.

2.	Generate the Table API. How

3. 	If you are generating Form modules that contain blocks based on stored procedures or views, generate the Module Component API. How


Generating the Table API

Where am I?

You can generate a set of PL/SQL packages, known as table handlers, to perform inserts, updates, deletions and locks on database tables.  About

When you generate table handlers, you can optionally generate a set of database triggers to provide validation on the server if a DML statement is issued against the base tables outside the calling application.

You can generate table handlers to one of the following targets:

•	an Oracle database, via a native Oracle Net8 connection

•	an Oracle script file that you can execute at a later stage  About

Note:	Table handlers must be created on the same database as the tables that will be accessed by the application.

To generate the Table API:

1.	Ensure that the database objects that will be used by your generated application are stable and complete, e.g. table definitions, sequence definitions, reference code tables, code control tables, domain tables etc.

If you subsequently change the database object definitions, you should regenerate the Table API.

2.	On the Navigator, select the Server Model tab

3.	Select one or more Relational Table Definitions for which a table handler is to be generated.

Note:	If generating the Table API for domain key constraints, ensure that all tables using the domain constraint table are selected.

4.	Choose Generate →Generate Table API.

5.	On the Target tab, choose one of the following generation targets:

•	File - to generate a script containing the commands to create the table handlers

•	Database - to create the table handlers on an Oracle database

6.	Do one of the following:

•	If you chose File, enter a name for the file and specify a directory for the generated file. The names and paths of previously generated files can be selected from the drop-down list.

If you omit the path, the file is generated to the current working directory.

•	If you chose Database, enter the Username, Password and Connect string to log on to the Oracle database.

7.	To generate additional Table API triggers which are only fired when DML statements are issued against the associated tables outside the calling application, ensure that the Generate Table API Triggers checkbox is selected.

8.	To store all generated files in the repository, check the Upload generated output to Repository checkbox. About

9.	Select the Objects tab.

10.	Move all tables that require a table handler to the Generate list.

11.	Select Start.

Next step

If you are generating Form modules whose blocks are based on stored procedures, your next step is to generate the Module Component API. How


Generating Table API triggers

Where am I?

When you generate Table API procedures from table definitions in the repository, you can optionally generate an accompanying set of database triggers. These triggers are only fired when DML statements are issued against the associated tables outside the calling application.  About

To generate Table API triggers:

1.	On the Navigator, select the Server Model tab.

2.	Select the tables for which the Table API procedures and triggers are to be generated.

Note:	If generating the Table API for domain key constraints, ensure that all tables using the domain constraint table are selected.

3.	Choose Generate →Generate Table API.

4.	Choose the target for generation.

5. 	Select the Generate Table API Triggers checkbox.

6.	To store all generated files in the repository, check the Upload generated output to Repository checkbox. About

7.	Select the Objects tab.

8.	Ensure that all tables for which procedures and triggers are to be generated are displayed in the Generate list.

9.	Select Start.

Next step

If you are generating Form modules whose blocks are based on stored procedures, your next step is to generate the Module Component API. How


Generating the Module Component API

Where am I?

You should generate the Module Component API if you have designed Form modules that contain blocks based on a stored procedure or a view.  About

You can generate Module Component API packages (or module handlers) to one of the following targets:

•	an Oracle database, via a native Oracle Net8 connection

•	an Oracle script file that you can execute at a later stage  About

Note:	You must create the module handlers on the same database as the Table API and database tables that will be accessed by the application.

To generate the Module Component API:

1.	On the Navigator, select the Modules tab.

2.	Select one or more module components for which module handlers are to be generated.

3.	Select Generate→Generate Module Component API.

4.	On the Target tab, choose one of the following generation targets:

•	File - to generate an Oracle script containing the commands to create the module handlers

•	Database - to create the module handlers on an Oracle database

5.	Do one of the following:

•	If you chose File, enter a name for the file and specify a directory for the generated file. The names and paths of previously generated files can be selected from the drop-down list.
If you omit the path, the file is generated to the current working directory.

•	If you chose Database, enter the Username, Password and Connect string to log on to the Oracle database.

6.	To store all generated files in the repository, check the Upload generated output to Repository checkbox. About

7.	Select the Objects tab.

8.	Move all modules that require a module handler to the Generate list.

9.	Select Start.

Next step

When you have generated the Module Component API, you are ready to generate the Form modules that will call the Module Component API procedures.


Generated Server API command files

Related Topics

When you generate Server API components to a file, commands to create the table handlers, triggers and module handlers are written to a set of command files.

A master command file .SQL calls all the generated package scripts (.PKS and .PKB) and trigger scripts (.TRG). You run the .SQL file to create the packages and triggers on the database.

Table API	File name
Master command file	<table_alias or table_name>.SQL
Package specification	<table_alias or table_name>.PKS
Package body	<table_alias or table_name>.PKB
Triggers	<table_alias or table_name>.TRG
Module Component API
Master command file	<module_component_name>.SQL
Package specification	<module_component_name>.PKS
Package body	<module_component_name >.PKB


Generated Table API code

Generated code

Table API components

Table API packages and procedures

Table API triggers

Validation

Validation checks performed by the Table API

Constraint validation performed by the Table API

Column values generated automatically by the Table API

How the Table API maintains uppercase column values

How the Table API validates allowable values in reference code tables

How the Table API validates domain constraints

How the Table API maintains denormalized columns

How the Table API maintains journal tables

Customization

Table API procedure events

Table API trigger events


Table API components

Related Topics

The following illustration shows how the Table API packages, procedures and triggers are generated from the table definitions in the repository.

Table API component	Name
Package (Table handler)	cg$<table_name>
PL/SQL records: Row Type Record Indicator Type Record Primary Key Type Record	cg$row_type cg$ind_type cg$pk_type
Insert procedure	ins
Update procedure	upd
Delete procedure	del
Lock procedure	lck


Table API packages and procedures

Related Topics      Example

The PL/SQL package (table handler) generated for each table contains the following components.

User-defined error messages

Column prompts

PL/SQL records

Insert procedure

Update procedure

Lock procedure

Delete procedure


Example of a table handler

The components of a table handler generated for a table EMP is shown below. The user-defined error messages are derived from the Error Message property in the constraint definition.  About

Column prompts are derived from the Prompt property in the column definition.  About

CREATE OR REPLACE PACKAGE cg$EMP IS
   --  Repository User-Defined Error Messages
   EMP_PK CONSTANT VARCHAR2(240) := 'Employee ID must be unique';

...

   --  Column default prompts
   P1_ID CONSTANT VARCHAR2(240) := 'Identification Number';
   P2_NAME CONSTANT VARCHAR2(240) := 'First Name';
   P3_ADDRESS CONSTANT VARCHAR2(240) := 'Address';

   --  EMP row type PL/SQL record

   TYPE cg$row_type IS RECORD ... ;

   --  EMP indicator type PL/SQL record
   TYPE cg$ind_type IS RECORD ... ;

   --  EMP primary key type PL/SQL record
   TYPE cg$pk_type IS RECORD ... ;
   PROCEDURE ins... ;
   PROCEDURE upd... ;
   PROCEDURE del... ;
   PROCEDURE lck... ;

END cg$EMP;


Table API - User-defined error messages

Related Topics

The Table API is used by the calling application to check that the operations being performed on tables do not violate the constraints that you have defined in the repository. If a constraint condition is not met, the Table API will attempt to output the user-defined error message recorded against that constraint definition. User-defined error messages can be recorded against constraint definitions using the Error Message property. How

If defined, these error messages are generated in the package specification (.PKS). The name of the CONSTANT generated for user defined error messages can be suffixed using the preference Generate Constant Suffix for Repository User Defined Error Messages (USERDM).

For example, the following user-defined message might be raised for an invalid primary key on the EMP table.

-- Repository User-Defined Error Messages
PK_EMP<suffix> CONSTANT VARCHAR2(240) := 'Employee ID must be unique'

If no user-defined error message is recorded for the constraint, a default error message is issued instead. The default error message can incorporate any column prompts that have been defined against the column definition.

For example, the following default error message might be issued if a value is omitted from a mandatory column.

'Value for <column_prompt or column_name> is required'


Table API - Column prompts

In Oracle Designer you can define prompts for columns to provide a more user-friendly way of referring to that column. For example, you might define a prompt 'Employee Number' as a way of identifying a column called EMPID. Column prompts are defined for columns using the column’s Prompt property.

How column prompts are used by the Table API

When a default error message is raised that involves a particular column, the error message can incorporate the column prompt as a means of identifying that column.  Any column prompts defined for the columns on a table are generated in the package specification (.PKS).

For example, a prompt 'Employee Number' defined for a primary key column EMPID would be generated in the package specification as follows:

-- Column default prompts:
P1_EMPID CONSTANT NUMBER(4) := 'Employee Number';

The prompt can then be incorporated in any default error messages that involve that column. For example:

'Value for Employee Number is required'

If no column prompt is defined for the column, the column name is used instead. For example:

'Value for EMPID is required'


PL/SQL records used by the Table API procedures

The Table API creates the following PL/SQL records to pass values to the procedures ins (insert), upd (update), lck (lock) and del (delete). These records are generated in the package specification (.PKS) created for each table.

Row Type Record (cg$row_type)

Indicator Type Record (cg$ind_type)

Primary Key Type Record (cg$pk_type)

Row type record

The Row Type Record cg$row_type is used by the procedures ins (insert), upd (update) and lck (lock).

The record is generated in the format:

TYPE cg$row_type IS RECORD

(column_name [table_name].[column_name]%TYPE

(,column_name [table_name].[column_name]%TYPE ...]

,the_rowid ROWID

,JN_NOTES VARCHAR2(240));

The insert and update procedures also use the information held by the Row Type Record to maintain journaling information for the table. A journal table is created if the Journal property is set in the table definition. When a row is inserted or updated, the JN_NOTES variable is used to populate the journal column JN_NOTES with the reason for the insert or update.

Indicator type record

The Indicator Type Record cg$ind_type is used by the procedures ins (insert), upd (update) and lck (lock) to indicate how column values are to be processed during insert, update and lock operations. For each value in the Row Type Record there is a corresponding boolean value defined in the Indicator Type Record. The indicator specifies whether the equivalent row type property is to be used to perform an insert or update or lock operation.

The boolean indicator can be set to TRUE or FALSE (the default). The record is generated in the format:

TYPE cg$ind_type IS RECORD

(column_name BOOLEAN default FALSE

[,column_name BOOLEAN default FALSE ...]);

When an application calls the insert, update or lock procedures, it provides the column values to be used in the Row Type Record. For any given column, it sets the equivalent indicator variable to TRUE if the supplied value is to be used by the procedure, or to FALSE if the procedure is to ignore the value. In this way, the application can explicitly use a NULL value. Without the indicator, the Table API would have no way of knowing if a NULL was the intended value or if the value was simply omitted.

The table below explains the effect of the indicator setting on a column value for different types of DML operation.

DML operation	Boolean indicator type	Effect on column value
insert	TRUE	The value is inserted, including values set to NULL.
	FALSE	The Table API will attempt to generate values automatically if the column is associated with a sequence, an AutoGen Type or has a predefined default value. Otherwise, the column is assumed to be NULL.
update	TRUE	The value is used to update the row, including values set to NULL.
	FALSE	The value is not part of the update and the column is not updated.
lock	TRUE	The value is compared against the corresponding column in the database.
	FALSE	The value is ignored when the current row is compared against the database.
delete	Not required
Primary key type record

The Primary Key Type Record cg$pk_type is used by the procedure del (delete) to identify the primary key of the row to be deleted.

The variables contained in the record represent the columns that make up the primary key of the table. The record is created in the format:

TYPE cg$pk_type IS RECORD

(column_name [table_name].[column_name]%TYPE

[,column_name [table_name].[column_name]%TYPE ...])

,the_rowid ROWID

,JN_NOTES VARCHAR2(240));

The delete procedure also uses the information held by the Primary Key Type record to maintain journalling information for the table. A journal table is created if the Journal property is set in the table definition. When a row is deleted, the JN_NOTES variable is used to populate the journal column JN_NOTES with the reason for the deletion.


Insert procedure (Table API)

Example

Inserts a new row in a table.

Syntax

PROCEDURE ins(cg$rec IN OUT cg$row_type
             ,cg$ind IN OUT cg$ind_type

 ,do_ins IN boolean default TRUE);

Parameters

cg$rec	A PL/SQL record containing the row to be inserted in the table.
cg$ind	A PL/SQL record containing boolean indicators showing which column values have been set.
do_ins	When TRUE, the package can fire INSERT DML.
Generated errors

An error is raised if the following condition occurs.

Error message name	Condition
VAL_MAND	The column is mandatory but no value has been specified.
How the insert procedure is used

Before a row can be inserted in a table, the Table API must be provided with the actual values to be inserted in each column, and a boolean indicator denoting which values have been explicitly provided by the application. For this purpose, the Table API uses two PL/SQL records:

•	Row Type Record

•	Indicator Type Record

These records are defined in the package generated for the table. The Row Type Record contains the values to be inserted into each column. The Indicator Type Record contains a corresponding indicator for each column. The indicator is used by the procedure to determine whether the equivalent value in the row type record is to be used or ignored.

When the procedure is called to insert a record, each inserted value is held in the corresponding row type variable for that column, and the boolean indicator is set to TRUE. The Table API checks that a value is provided for all mandatory columns, and raises an error if necessary.

If no value is provided by the application, the indicator type for that column is set to FALSE. In this instance, the Table API will attempt to generate a value automatically. If no value is auto-generated, the value is assumed to be NULL. The following types of values can be generated automatically:

•	predefined default values

•	sequence numbers, generated either from Oracle sequences or code controls tables

•	change history information, such as Created by, Date Created

•	derived values, i.e. derivation expression defined

Before inserting a row, the Table API also:

•	converts values to uppercase, if the column is defined as Uppercase only

•	populates the journal column JN_NOTES with the reason for the insert, if the table has an associated journal table

All values successfully inserted in the table are passed back to the calling application.


Example: Calling the Table API Insert procedure

You can call the Table API Insert procedures generated for each table when building your application code. In this example, the Insert procedure is called to insert a new employee record in the Employees table.

DECLARE

   -- PL/SQL Records to pass values to the Insert procedure

   new_employee  cg$emp.cg$row_type;

   new_emp_inds  cg$emp.cg$ind_type;

BEGIN

   -- Set the initial values for the new employee

   new_employee.empno := 1490;

   new_employee.ename := 'SCOTT';

   new_employee.job   := 'MANAGER';

   -- Set the indicator type for the above data

   new_emp_inds.empno := TRUE;

   new_emp_inds.ename := TRUE;

   new_emp_inds.job   := TRUE;

   -- Call the Table API Insert procedure

   cg$emp.ins(new_employee,new_emp_inds);

EXCEPTION

   -- Catch any errors raised by the Table API

   WHEN cg$errors.cg$error THEN

      -- Display errors using the dbms_output package

      dbms_output.put_line(cg$errors.GetErrors);

      -- Raise the exception to rollback changes made in this block

      raise;

END;


Update procedure (Table API)

Example

Updates an existing row in a table.

Syntax

PROCEDURE upd(cg$rec IN OUT cg$row_type
             ,cg$ind IN OUT cg$ind_type

 ,do_upd IN boolean default TRUE);

Parameters

cg$rec	A PL/SQL record containing the row to be updated in the table.
cg$ind	A PL/SQL record containing boolean indicators showing which values have been set.
do_upd	When TRUE, the package can fire UPDATE DML.
Generated errors

An error is raised if any of the following conditions occur.

Error message name	Condition
ERR_UK_UPDATE	The primary key cannot be updated.
ERR_FK_TRANS	The foreign key cannot be updated.
VAL_MAND	The column is mandatory but a NULL value has been specified.
ROW_DEL	The row has been deleted by another user.
How the Update procedure is used

To perform an update using the Table API, the following PL/SQL records must be populated:

•	Row Type Record

•	Indicator Type Record

These records are defined in the package generated for the table. Each value to be used to update the row is specified by setting the appropriate variables in the Row Type Record. The equivalent variable in the indicator type record is set to TRUE. When set to TRUE, the indicator specifies that the value in the Row Type Record is to be used to update the row, even if that value is NULL.

When an indicator variable is set to FALSE, the Table API does not attempt to update the equivalent column.

The Table API identifies each row to be updated in the table by the primary key, therefore the primary key cannot be updated. The API checks that all mandatory values are provided and prevents updates on non-updateable foreign key and unique key columns.

Before updating a row, the Table API also:

•	generates change history information, such as Modified by, Date Modified

•	converts values to uppercase, if the column is defined as Uppercase only

•	populates the journal column JN_NOTES with the reason for the update if a journal table has been generated for the table

After a successful update, the values used to update the row are passed back to the calling application, where they may be reused if required.


Example: Calling the Table API Update procedure

You can call the Table API Update procedures generated for each table when building your application code. In this example, the Update procedure is called to update the records of all managers in the Employees table.

DECLARE

   -- PL/SQL Records used to pass values to the Update procedure

   employee  cg$emp.cg$row_type;

   emp_inds  cg$emp.cg$ind_type;

   -- Cursor to fetch rows directly into cg$emp.cg$row_type type

   CURSOR ManagementJobs(job_to_check  IN emp.job%type

                        ,sal_limit     IN emp.sal%type)

   RETURN cg$emp.cg$row_type

   IS

   SELECT  deptno, empno, ename, job, mgr, hiredate, sal, comm, ''

   FROM emp

   WHERE job = job_to_check

   AND   sal > sal_limit

   ;

BEGIN

   -- As we are only concerned with the primary key and salary

   -- just set the indicators for those columns

   emp_inds.empno      := TRUE;

   emp_inds.sal        := TRUE;

   -- Get all managers and update their salary

   -- by calling the Table API Update procedure

   OPEN ManagementJobs('MANAGER',2000);

   LOOP

     FETCH ManagementJobs INTO employee;

     EXIT WHEN ManagementJobs%NOTFOUND;

     employee.sal := 2000;

     cg$emp.upd(employee,emp_inds);

   END LOOP;

   CLOSE ManagementJobs;

EXCEPTION

   -- trap any errors raised by the Table API

   WHEN cg$errors.cg$error THEN

      -- Display errors using the dbms_output package

      dbms_output.put_line(cg$errors.GetErrors);

      -- Raise the exception to rollback changes made in this block

      raise;

END;


Delete procedure (Table API)
Delete procedure [Table API]

Example

Deletes a row from a table.

Syntax

PROCEDURE del(cg$pk IN cg$pk_type
             ,do_del IN boolean default TRUE)

Parameters

cg$pk	A PL/SQL record used to identify the row to be deleted in a table by its primary key.
do_ins	When TRUE, the package can fire DELETE DML.
Generated errors

An error is raised if the following condition occurs.

Error message name	Condition
ERR_DEL_RESTRICT	Deletion is restricted because the row to be deleted is referenced by another table.
How the Delete procedure is used

To delete a row from a table, the Table API uses the Primary Key Type Record to identify the primary key of the row to be deleted. The record is populated with the column values of the relevant primary key.

When a row is deleted, the Delete procedure populates the journal column JN_NOTES with the reason for the deletion, if a journal table is associated with the table.


Example: Calling the Table API Delete procedure

You can call the Table API Delete procedure in your own application code. In this example, the Delete procedure is called to delete, from the Employees table, the records of all salesmen who do not earn commission.

DECLARE

   -- PL/SQL Record to pass primary key values
   -- to the Delete procedure

   employee cg$emp.cg$pk_type;

BEGIN

   -- Delete all salesmen without commission

   --

   FOR to_del In (SELECT  empno

                  FROM emp

                  WHERE job  = 'SALESMAN'

                  AND   comm = 0

                 )

   LOOP

       employee.empno := to_del.empno;

       cg$emp.del(employee);

   END LOOP;

EXCEPTION

   -- Catch any errors raised by the Table API

   WHEN cg$errors.cg$error THEN

      -- Display errors using the dbms_output package

      dbms_output.put_line(cg$errors.GetErrors);

      -- Raise the exception to rollback changes made in this block

      raise;

END;


Lock procedure (Table API)

Example

Locks a row in a table.

Syntax

PROCEDURE lck (cg$old_rec IN cg$row_type

              ,cg$old_ind IN cg$ind_type
              ,nowait IN boolean default TRUE);

Parameters

cg$old_rec	A record of the values previously queried.
cg$old_ind	A record of the indicator flags for each value previously queried.
cg$row_type	A PL/SQL record containing the row to be updated in the table.
cg$ind_type	A PL/SQL record containing a list of boolean indicators showing which values have been set explicitly by the user.
Generated errors

An error is raised if any of the following conditions occur.

Error message name	Condition
ROW_DEL	The row has been deleted by another user.
ROW_LCK	The row is locked by another user and NOWAIT is specified.
ROW_MOD	The row has been modified by another user.
	When a row has been modified by another user, the values that are changed can be placed on the error stack. If defined, the Date-Modified and user-modified flags may be displayed.
How the Lock procedure is used

To lock a row, the Table API must be passed two records, containing:

•	the values believed to be the current values of the row, prior to update

•	a boolean indicator for each column

The indicator type is used to determine which column values are to be compared against the database values. When the indicator type is set to TRUE, the Lock procedure will compare the column against its database equivalent. If the values are different, the row has been updated by another user and an error is pushed onto the error stack. The error message returns details about the user who updated the row and the date the row was updated, if these autogenerated columns are defined.

If the values compared by the procedure are the same, the row can be locked. The lock may still occur even if the values are different, provided that the indicator type for the column is set to FALSE.

The API identifies the row to be locked by the primary key, therefore the primary key must be specified. By default, the row is locked with the NOWAIT option, but can be changed if required.


Example: Calling the Table API Lock procedure

You can call the Table API Lock procedure in your own application code. In this example, the Lock procedure is called to lock the record of the employee SMITH.

DECLARE

   -- PL/SQL Records used to pass values to the Lock procedure

   employee  cg$emp.cg$row_type;

   emp_ind   cg$emp.cg$ind_type;

BEGIN

   -- lock the employee record whose employee number is = 42

   --

   employee.empno := 42;

   emp_ind.empno := TRUE;

   -- Also verify that the name is still SMITH

   employee.ename := 'SMITH';

   emp_ind.ename := TRUE;

   -- call the Table API Lock procedure to lock the record with NOWAIT

   -- For WAIT, use cg$emp.lck(employee,emp_ind, FALSE);

   cg$emp.lck(employee,emp_ind);

EXCEPTION

   -- Catch any errors raised by the Table API

   WHEN cg$errors.cg$error THEN

      -- Display errors using the dbms_output package

      dbms_output.put_line(cg$errors.GetErrors);

      -- Raise the exception to rollback changes made in this block

      raise;

END;


Table API triggers

Related Topics

When you generate the Table API, a set of database triggers can be generated for each table. The triggers are fired when an INSERT, UPDATE or DELETE statement is issued directly against the table on the database.

The triggers fire before and after each statement and before and after each row.

You can customize the functionality provided by the Table API triggers by defining your own event code segments that can be executed either before or after the trigger action.

About

Trigger	Prefix	Description	Fires
Before Insert Statement	CG$BIS	Deletes the PL/SQL table of records and resets the index pointer to 1.	Before each insert statement
Before Insert Row	CG$BIR	Loads the table records (cg$rec) with the values passed in from the INSERT statement. This trigger calls the procedure validate_arc to check that a value is provided in at least one arc column. It also calls the validate_domain procedure to validate allowable values against the reference code table or domain table. If the values in the table of records are valid, the Table API Insert procedure is called to perform the insert.	Before each row is inserted.
After Insert Row	CG$AIR	Executes any user-defined event code segments defined for this trigger.	After each insert statement
After Insert Statement	CG$AIS	Calls the Table API to maintain any denormalized columns.	After each insert statement
Before Update Statement	CG$BUS	Deletes the PL/SQL table of records and resets the index pointer to 1.	Before each update statement
Before Update Row	CG$BUR	Loads the table records (cg$rec) with the values passed in from the INSERT statement.	Before each row is updated.
After Update Row	CG$AUR	Executes any user-defined event code segments defined for this trigger.	After each row is updated
After Update Statement	CG$AUS	Calls the Table API procedure to validate foreign key Cascade Update rules. If the table contains denormalized columns, the denormalization procedure is called to maintain the denormalization. The PL/SQL table of records is then deleted.	After each update statement
Before Delete Statement	CG$BDS	Deletes the PL/SQL table of records and resets the index pointer to 1.	Before each delete statement
Before Delete Row	CG$BDR	Loads the primary key record (cg$pk) with the primary key passed in from the DELETE statement. This trigger calls the Table API Delete procedure to delete the row.	Before each row is deleted
After Delete Row	CG$ADR	Executes any user-defined event code segments defined for this trigger.	After each row is deleted
After Delete Statement	CG$ADS	Calls the Table API procedure to maintain denormalized columns.	After each delete statement


Module Component API

Module Component API procedures

Module Component API procedure events


Module Component API procedures

Example

Query procedure

Insert procedure

Update procedure

Delete procedure

Lock procedure

Module Component API command files

The Module Component API packages are created from a set of command files:

•	master command file	<file_prefix>.SQL

•	package specification file	<module_name>.PKS

•	package body file	<module_name>.PKB

The master command file contains instructions to call the generated package scripts (.PKS and .PKB). You can run this file to create the module handlers on an Oracle database.

Names of Module Component API procedures

Package (Module handler)	cgc$<module_component_name>
Query procedure	qry
Insert procedure	ins
Update procedure	upd
Delete procedure	del
Lock procedure	lck


Example of a module handler

The components of a module handler generated for a module component MOD_COMP is shown below.

CREATE OR REPLACE PACKAGE cgc$MOD_COMP IS
-- PL/SQL records

      TYPE cgc$rec IS RECORD (...);

      TYPE cgc$rec_tab IS TABLE OF cgc$rec INDEX BY BINARY_INTEGER;

-- PL/SQL procedures
      PROCEDURE ins(...);
      PROCEDURE upd(...);
      PROCEDURE del(...);
      PROCEDURE lck(...);

      PROCEDURE qry(...);

END cgc$MOD_COMP;


Query procedure (Module Component API)
Query procedure [Module Component API]

Performs a query on a table.

Syntax

PROCEDURE qry(cgc$rec_rows IN OUT cgc$rec_tab,

              where_clause IN VARCHAR2 DEFAULT ' ')

Parameters

cgc$rec	A PL/SQL record containing the values provided by the application.
where_clause	A SQL condition that restricts the rows returned from the results of the query.


Insert procedure (Module Component API)
Insert procedure [Module Component API]

Inserts a new row in a table. This procedure calls the Table API Insert procedure to perform the insert.

Syntax

PROCEDURE ins(cgc$rec_rows IN cgc$rec_tab);

Parameters

cgc$rec_rows	A PL/SQL record containing the row to be inserted in the table.
cgc$rec_tab	A PL/SQL record containing boolean indicators showing which column values have been set.
How the insert procedure is used

This procedure uses a set of PL/SQL records to call the generated Table API insert procedure.

•	Row Type Record

•	Indicator Type Record

These records are defined in the package specification generated for the module component. The Indicator Type Record is used by the procedure to determine which columns are used by the module component. The Row Type Record is used to pass the values to be inserted into the table to the Table API Insert procedure. The Table API Insert procedure is then called to insert the rows into the table on the database.


Update procedure (Module Component API)
Update procedure [Module Component API]

Updates an existing row in a table. This procedure calls the Table API Update procedure to perform the update.

Syntax

PROCEDURE upd(cgc$rec_rows IN cgc$rec_tab);

Parameters

cgc$rec_rows	A PL/SQL record containing the row to be updated in the table.
cgc$rec_tab	A PL/SQL record containing boolean indicators showing which column values have been set.
How the Update procedure is used

This procedure uses the PL/SQL records Row Type Record and Indicator Type Record to call the Table API update procedure to update rows in the table.


Delete procedure (Module Component API)
Delete procedure [Module Component API]

Deletes an existing row in a table. This procedure calls the Table API Delete procedure to perform the deletion.

Syntax

PROCEDURE del(cgc$pk_rows IN cgc$pk_rec_tab);

Parameters

cgc$pk_rows	A PL/SQL record used to identify the row to be deleted from the table, by the primary key.
How the Delete procedure is used

This procedure uses the Primary Key Type Record to pass the values to be deleted from the table to the Table API Delete procedure.


Lock procedure (Module Component API)
Lock procedure [Module Component API]

Locks a row in a table. This procedure calls the Table API Lock procedure to lock the row.

Syntax

PROCEDURE lck(cgc$rec_rows IN cgc$rec_tab),

              nowait_flag IN BOOLEAN DEFAULT TRUE);

Parameters

cgc$rec_rows	A PL/SQL record containing the values to be updated in the table.
How the Lock procedure is used

This procedure uses the Row Type Record to pass the values believed to be the current values of the row prior to an update to the Table API Lock procedure. The Indicator Type Record is used to determine which column values are to be compared against the database values. If the values passed in are the same as the database values, then the Table API Lock procedure is called to lock the row.


About customizing the Table API

Related Topics

Note:	The Table API is only supported on Oracle7.3 database and above.

Generated Oracle Designer applications can call Table API procedures to insert, update, delete and lock rows in the application tables. If your applications call the Table API, you can optionally define your own event code segments to perform additional operations on a table at pre-defined event points within the generated code. For example, you might define event code to record auditing information after a row is inserted or updated in a table.

Event code segments are units of PL/SQL and SQL logic that you write for an event on a specific table. A set of pre-defined events are provided, that are called from Pre and Post event points within the generated code. There are two categories of events:

•	Table API procedure events  About

•	Table API trigger events  About

How do I customize the Table API?

You define event code segments for an event on a table using the Logic Editor. How

An event code segment can consist of:

•	discreet units of code to perform some operation on a table

•	calls to user-defined stored procedures

The event code segments are held against the event type in the repository. When you generate the Table API procedures and triggers, your code segments are included in the generated code at the specified event points. If you define more than one event code segment for a particular event, you must also specify the order in which the code is to be executed.

The following illustration shows where in the generated code your event code segments will be placed. When defining event code segments, you should bear in mind that generated Table API triggers call the Table API procedures to perform DML operations on tables, therefore any code you define in the procedure will also be executed from the trigger.

When a Table API procedure is called directly from an application, the event code segments embedded within that procedure only are executed. When a Table API trigger is fired implicitly for a table, then any pre-event code segments defined for the trigger are executed first, followed by the trigger code, called procedure code, and finally post-event trigger code.


Customizing the Table API

Where am I?

You can create your own event code segments for Table API procedures and triggers, to perform additional operations on tables before and after a row is inserted, updated, deleted or locked via the Table API.

Event code segments are defined and edited using the Logic Editor. Before customizing the behavior of the Table API, you should be familiar with the functionality already provided.  About

To define event code segments for Table API procedures and triggers:

1.	In the Design Editor, select the Server Model view in the Navigator.

2.	Expand the table node that contains the Table API code to be customized.

3.	Select the Table API/Trigger Logic node.

4.	Click

5.	Choose the type of event you want to define.

−	Procedure events  About

−	Trigger events  About

6.	(Optional) Enter a name for the event, and a comment about the purpose of the event code.

7.	Specify the order in which the event is be executed in relation to the generated code.

8.	In the Logic Editor, enter a PL/SQL block or statement to be executed from the event point. For example:

    BEGIN

     /*  Enter the event code  */

    END;

To edit event code segments:

1.	In the Navigator, select the event code segment you have defined.

2.	Choose Edit→Logic.


Table API procedure events

The following events can be defined to execute within generated Table API procedures, before and after a row in a table is inserted, updated, deleted or locked.

Each event is executed at pre-defined event points within the generated code:

Pre	Pre-event code can be defined to enhance the information passed in by the calling application, before a table is modified.
Post	Post-event code can be defined to pass additional information back to the calling application after a table is modified via the Table API, such as the number of times a row was inserted.
Event	Description	Executed within Table API procedure
Pre-Insert	A PL/SQL block or statement that is executed before each row is inserted.	Insert procedure [Table API]
Post-Insert	A PL/SQL block or statement that is executed after each row is inserted.	Insert procedure [Table API]
Pre-Update	A PL/SQL block or statement that is executed before each row is updated.	Update procedure [Table API]
Post-Update	A PL/SQL block or statement that is executed after each row is updated.	Update procedure [Table API]
Pre-Delete	A PL/SQL block or statement that is executed before each row is deleted.	Delete procedure [Table API]
Post-Delete	A PL/SQL block or statement that is executed after each row is deleted.	Delete procedure [Table API]
Pre-Lock	A PL/SQL block or statement that is executed before each row is locked.	Lock procedure [Table API]
Post-Lock	A PL/SQL block or statement that is executed after each row is locked.	Lock procedure [Table API]
Pre-Query	A PL/SQL block or statement that is executed before each row is queried.
Post-Query	A PL/SQL block or statement that is executed after each row is queried.


Table API trigger events

Related Topics

The following events can be defined to execute within generated Table API triggers, before and after a row in a table is inserted, updated or deleted.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Statement-level events are executed once for each row affected by the trigger statement. Row-level events are fired once for each statement, irrespective of the number of rows inserted, updated or deleted.

Each event is executed at pre-defined event points within the generated code:

Pre	Pre-event code can be defined to enhance the information passed in by the calling application, before a table is modified.
Post	Post-event code can be defined to pass additional information back to the calling application after a table is modified via the Table API, such as the number of times a row was inserted.
Event	Description	Called from trigger:
After-Delete-row	Executes once after each row is deleted from a table.	CG$ADR<table_name>
After-Delete-stmt	Executes once after a DELETE statement is issued against a table.	CG$ADS<table_name>
After-Insert-row	Executes once after each row is inserted in a table.	CG$AIR<table_name>
After-Insert-stmt	Executes once after an INSERT statement is issued against a table.	CG$AIS<table_name>
After-Update-row	Executes once after each row is updated in a table.	CG$AUR<table_name>
After-Update-stmt	Executes once after an UPDATE statement is issued against a table.	CG$AUS<table_name>
Before-Delete-row	Executes once before each row is deleted from the table.	CG$BDR<table_name>
Before Delete-stmt	Executes once before a DELETE statement is issued against a table.	CG$BDS<table_name>
Before-Insert-row	Executes once before each row is inserted in a table.	CG$BIR<table_name>
Before-Insert-stmt	Executes once before an INSERT statement is executed against the table.	CG$BIS<table_name>
Before-Update-row	Executes once before each row is updated in a table.	CG$BUR<table_name>
Before-Update-stmt	Executes once before an UPDATE statement is executed against a table.	CG$BUS<table_name>


About customizing the Module Component API

Generated Oracle Forms applications can call generated Module Component API procedures to perform queries and DML operations on the application tables. If your applications call the Module Component API, you can define your own event code segments to perform additional operations on a table at pre-defined event points within the generated code.

Event code segments can be defined for Pre and Post event types.  About

Note:	The Module Component API is only supported on Oracle7.3 database and above.

The following illustration shows where in the generated code your event code segments will be placed. When defining event code segments, you should bear in mind that generated Module Component API procedures call the Table API procedures to perform DML operations on tables; therefore any code you defined for the Table API will also be executed.


Customizing the Module Component API

Where am I?

You can create your own event code segments for Module Component API procedures, to perform additional operations on tables before and after queries and DML operations are performed on your application tables.

To define event code segments for Module Component API procedures:

1.	In the Design Editor, select the Modules view in the Navigator.

2.	Expand the Module Component node that contains the module component for which event code segments are to be defined.

3.	Select the Module Component API Logic node.

4.	Click

5. 	Choose the type of event you want to define.  About

6.	(Optional)  Enter a name for the event and a comment about the purpose of the event code.

7.	If you are defining more than one code segment for an event, specify the order in which the event code is to be executed in relation to the generated code.

8.	In the Logic Editor, enter the PL/SQL and SQL code to be executed from the event point, in the format:

    BEGIN

     /*  Enter the event code  */

    END;

To edit event code segments:

1.	In the Navigator, select the event code segment you have defined.

2.	Choose Edit→Logic.


Module Component API procedure events

The following events can be defined to execute within generated Module Component API procedures, before and after queries and DML operations are performed on tables.

Event	Description	Executed within  Module Component API procedure:
Pre-Insert	A PL/SQL block or statement that is executed before each row is inserted in a table.	Insert procedure [Module Component API]
Post-Insert	A PL/SQL block or statement that is executed after each row is inserted in a table.	Insert procedure [Module Component API]
Pre-Update	A PL/SQL block or statement that is executed before each row is updated in a table.	Update procedure [Module Component API
Post-Update	A PL/SQL block or statement that is executed after each row is updated in a table.	Update procedure [Module Component API
Pre-Delete	A PL/SQL block or statement that is executed before each row is deleted from a table.	Delete procedure [Module Component API]
Post-Delete	A PL/SQL block or statement that is executed after each row is deleted from a table.	Delete procedure [Module Component API]
Pre-Lock	A PL/SQL block or statement that is executed before each row is locked in a table.	Lock procedure [Module Component API]
Post-Lock	A PL/SQL block or statement that is executed after each row is locked in a table.	Lock procedure [Module Component API]
Pre-Query	A PL/SQL block or statement that is executed before each query is performed on a table.	Query procedure [Module Component API]
Post-Query	A PL/SQL block or statement that is executed after each query is performed on a table.	Query procedure [Module Component API]


Table API derivation support

Derivation support allows a user to define that a column of a table automatically takes its value from a user entered expression or from the AutoGen type property.

User entered expression

Take the table called PERSON with the columns:

•	PERSON_ID : NUMBER(38)

•	NAME : VARCHAR2(50)

•	MONTHLY_SALARY : NUMBER(20)

•	ANNUAL_SALARY : NUMBER(38)

1.	Define a ‘Derivation Expression’ against the column ANNUAL_SALARY, for instance:MONTHLY_SALARY*12

2.	Set the ‘Derivation Expression Type’ to SQL Expression

3.	Set the column derivation property Server Derived ? to Yes

The Table API will generate the code, keeping the value in the column always equal to the evaluation of the ‘Derivation Expression’.

Note:	If Server Derived ? is set to Yes, generated applications that use this column should re-query the row after insert/update to display server derived value.

AutoGen type

This specifies whether the column value should be automatically generated in a client application, and the type of value to be generated. This option is used by the Generator products to maintain change history information for auditing purposes. Values for this column are set automatically in the client. Any items in the generated application that are based on columns whose AutoGen Type is not null are made non-enterable.

Note:	If the table has been generated using the Database Design Transformer, defaults for this option are automatically set.

The available options are:

Option	Description

< null >	Values for this column are not automatically generated. The Database Design Transformer generally sets the AutoGen Type to null.

Created by	Sets the column value to the name of the user who created the row.

Date Created	Sets the column value to the date that the row was created.

Date Modified	Sets the column value to the date that the row was last modified.

Modified by	Sets the column value to the name of the user who last modified the row.

Seq in Parent	Sets the column value to the next unique number within the referenced primary key, when a new record is created. The Database Design Transformer sets the AutoGen Type to Seq in Parent if the column has been generated from an attribute whose format is NUMBER and that is also part of a unique identifier made up of attributes and relationships.


Table API trigger event: Pre-After-Delete-row

The following event can be defined to execute within generated Table API triggers, after a row in a table is deleted.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-After-Delete-row	Executes once after each row is deleted from a table.	CG$ADR<table_name>


Table API trigger event: Pre-After-Delete-stmt

The following event can be defined to execute within generated Table API triggers, after a DELETE statement is issued against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-After-Delete-stmt	Executes once after a DELETE statement is issued against a table.	CG$ADS<table_name>


Table API trigger event: Pre-After-Insert-row

The following event can be defined to execute within generated Table API triggers, after a row is inserted in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-After-Insert-row	Executes once after each row is inserted in a table.	CG$AIR<table_name>


Table API trigger event: Pre-After-Insert-stmt

The following event can be defined to execute within generated Table API triggers, after an INSERT statement is issued against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-After-Insert-stmt	Executes once after an INSERT statement is issued against a table.	CG$AIS<table_name>


Table API trigger event: Pre-After-Update-row

The following event can be defined to execute within generated Table API triggers, after a row is updated in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-After-Update-row	Executes once after each row is updated in a table.	CG$AUR<table_name>


Table API trigger event: Pre-After-Update-stmt

The following event can be defined to execute within generated Table API triggers, after an UPDATE statement is issued against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-After-Update-stmt	Executes once after an UPDATE statement is issued against a table.	CG$AUS<table_name>


Table API trigger event: Pre-Before-Delete-row

The following event can be defined to execute within generated Table API triggers, before a row is deleted from the table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-Before-Delete-row	Executes once before each row is deleted from the table.	CG$BDR<table_name>


Table API trigger event: Pre-Before-Delete-stmt

The following event can be defined to execute within generated Table API triggers, before a DELETE statement is issued against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-Before Delete-stmt	Executes once before a DELETE statement is issued against a table.	CG$BDS<table_name>


Table API trigger event: Pre-Before-Insert-row

The following event can be defined to execute within generated Table API triggers, before a row is inserted in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-Before-Insert-row	Executes once before each row is inserted in a table.	CG$BIR<table_name>


Table API trigger event: Pre-Before-Insert-stmt

The following event can be defined to execute within generated Table API triggers, before an INSERT statement is executed against the table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-Before-Insert-stmt	Executes once before an INSERT statement is executed against the table.	CG$BIS<table_name>


Table API trigger event: Pre-Before-Update-row

The following event can be defined to execute within generated Table API triggers, before a row is updated in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-Before-Update-row	Executes once before each row is updated in a table.	CG$BUR<table_name>


Table API trigger event: Pre-Before-Update-stmt

The following event can be defined to execute within generated Table API triggers, before an UPDATE statement is executed against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Pre-Before-Update-stmt	Executes once before an UPDATE statement is executed against a table.	CG$BUS<table_name>


Table API trigger event: Post-After-Delete-row

The following event can be defined to execute within generated Table API triggers, after a row is deleted in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-After-Delete-row	Executes once after each row is deleted in a table.	CG$ADR<table_name>


Table API procedure events: Pre-Insert

The following event can be defined to execute within generated Table API procedures, before a row is inserted in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Pre-Insert	A PL/SQL block or statement that is executed before each row is inserted.	Insert procedure [Table API]


Table API procedure events: Post-Insert

The following event can be defined to execute within generated Table API procedures, after a row is inserted in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Post-Insert	A PL/SQL block or statement that is executed after each row is inserted.	Insert procedure [Table API]


Table API procedure events: Pre-Update

The following event can be defined to execute within generated Table API procedures, before a row is updated in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Pre-Update	A PL/SQL block or statement that is executed before each row is updated.	Update procedure [Table API]


Table API procedure events: Post-Update

The following event can be defined to execute within generated Table API procedures, after a row is updated in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Post-Update	A PL/SQL block or statement that is executed after each row is updated.	Update procedure [Table API]


Table API procedure events: Pre-Delete

The following event can be defined to execute within generated Table API procedures, before a row is deleted in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Pre-Delete	A PL/SQL block or statement that is executed before each row is deleted.	Delete procedure [Table API]


Table API procedure events: Post-Delete

The following event can be defined to execute within generated Table API procedures, after a row is deleted in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Post-Delete	A PL/SQL block or statement that is executed after each row is deleted.	Delete procedure [Table API]


Table API procedure events: Pre-Lock

The following event can be defined to execute within generated Table API procedures, before a row is locked in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Pre-Lock	A PL/SQL block or statement that is executed before each row is locked.	Lock procedure [Table API]


Table API procedure events: Post-Lock

The following event can be defined to execute within generated Table API procedures, after a row is locked in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Post-Lock	A PL/SQL block or statement that is executed after each row is locked.	Lock procedure [Table API]


Table API procedure events: Post-Query

The following event can be defined to execute within generated Table API procedures, after a row is queried in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Post-Query	A PL/SQL block or statement that is executed after each row is queried.


Table API procedure events: Pre-Query

The following event can be defined to execute within generated Table API procedures, before a row is queried in a table.

Each event is executed at pre-defined event points within the generated code:

Event	Description	Executed within Table API procedure
Pre-Query	A PL/SQL block or statement that is executed before each row is queried.


Table API trigger event: Post-After-Delete-stmt

The following event can be defined to execute within generated Table API triggers, after a DELETE statement is issued against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-After-Delete-stmt	Executes once after a DELETE statement is issued against a table.	CG$ADS<table_name>


Table API trigger event: Post-After-Insert-row

The following event can be defined to execute within generated Table API triggers, after a row is inserted in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-After-Insert-row	Executes once after each row is inserted in a table.	CG$AIR<table_name>


Table API trigger event: Post-After-Insert-stmt

The following event can be defined to execute within generated Table API triggers, after an INSERT statement is issued against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-After-Insert-stmt	Executes once after an INSERT statement is issued against a table.	CG$AIS<table_name>


Table API trigger event: Post-After-Update-row

The following event can be defined to execute within generated Table API triggers, after a row is updated in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-After-Update-row	Executes once after each row is updated in a table.	CG$AUR<table_name>


Table API trigger event: Post-After-Update-stmt

The following event can be defined to execute within generated Table API triggers, after an UPDATE statement is issued against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-After-Update-stmt	Executes once after an UPDATE statement is issued against a table.	CG$AUS<table_name>


Table API trigger event: Post-Before-Delete-stmt

The following event can be defined to execute within generated Table API triggers, before a DELETE statement is issued against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-Before Delete-stmt	Executes once before a DELETE statement is issued against a table.	CG$BDS<table_name>


Table API trigger event: Post-Before-Insert-row

The following event can be defined to execute within generated Table API triggers, before a row is inserted in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-Before-Insert-row	Executes once before each row is inserted in a table.	CG$BIR<table_name>


Table API trigger event: Post-Before-Insert-stmt

The following event can be defined to execute within generated Table API triggers, before an INSERT statement is executed against the table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-Before-Insert-stmt	Executes once before an INSERT statement is executed against the table.	CG$BIS<table_name>


Table API trigger event: Post-Before-Update-row

The following event can be defined to execute within generated Table API triggers, before a row is updated in a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-Before-Update-row	Executes once before each row is updated in a table.	CG$BUR<table_name>


Table API trigger event: Post-Before-Update-stmt

The following event can be defined to execute within generated Table API triggers, before an UPDATE statement is executed against a table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-Before-Update-stmt	Executes once before an UPDATE statement is executed against a table.	CG$BUS<table_name>


Table API trigger event: Post-Before-Delete-row

The following event can be defined to execute within generated Table API triggers, before a row is deleted from the table.

Note:	Table API triggers call generated Table API procedures to perform the DML operations on the tables; therefore any procedure event code you define will also be executed.

Event	Description	Called from trigger:
Post-Before-Delete-row	Executes once before each row is deleted from the table.	CG$BDR<table_name>


About code control tables

What is a code control table?

A code control table is a database table that is generated to provide unique and sequential numbers for items in generated applications that derive their values from a code control sequence. How

When should I use a code control table?

You should specify column value derivation from a code control table if the values to be auto-generated for numeric columns must always be sequential and/or the target for generation is another database. When the target for generation is an Oracle database, unique values are auto-generated from an Oracle sequence, rather than a code control table, but the numbers are not guaranteed to be in an unbroken sequence.

Generated applications can reference the values in the code control table to provide unique numbers for the following types of module:

•	Form

•	Web PL/SQL

•	Visual Basic

Generated applications can fetch the next unique number to be autogenerated from the code control table in one of the following ways:

•	via Table API procedures, if you have specified derivation on the server by setting the column Derivation property Server Derived to Yes. How

•	via client-side code, if you have specified derivation on the client by setting the column Server Derived property to No (the default).

Generated code control tables

During generation, Server Generator creates the code control table and inserts a row in the table to store details about the code control sequence. Each row in the code control table records the sequence name, the next value to be automatically generated during an insert operation (Start property), the increment value (Increment property) and any comment recorded about the sequence in the repository (Comment property).

By default, a single table CG_CODE_CONTROLS is generated to provide unique identifiers for all modules in the container. Alternatively, you can set the Scope Of Code Control Table Option to generate a table for a specific container, or for a specific table.  About

You specify where the code control table is to be generated when you generate the sequence definition, either on an online database catalog or to a DDL script that you can run to create the table on the target database. How

DDL statements to create both the code control sequence and code control table are written to separate command files, i.e. <file_prefix>.ccs and <file_prefix>.tab respectively.

Note:	The code control table must exist in the same database that will be accessed by the generated application.

After the code control table is initially created, new entries are inserted in the table for each additional code control sequence that you generate.

When should I manually update the code control table?

You should generate code control sequence definitions:

•	before generating the Server API  About

•	before generating modules containing items that derive values from a code control sequence

•	after changing a code control sequence definition that is used by your modules, or associating another column with a code control sequence

To manually update the code controls table

Select the Generate Database from Server Model utility, and from the Objects tab select the code control sequence to be generated. How

From the Target tab run the utility with the specified options. How


Scope of code control table

Related Topics

To set the scope of the generated code control tables, choose Options→Generator Options→General.

This option defines the scope of the code control table that is used to generate unique identifiers for items based on columns that derive values from a code control sequence.

The code control table can be populated with details about code control sequences that exist in all containers, in a specific container or that are associated with a specific table.

Options	Description	Name
Container Wide Table	Generates and populates a different code control table for each container.	<container_name>_CODE_CONTROLS
Single Table	Generates and populates a single code control table for all containers.	CG_CODE_CONTROLS
Table for each Code Control	Generates and populates a different code control table for each table that derives a value from a code control sequence.	<table_name>_CC


About database column datatypes
About database datatypes

Related Topics

A column's datatype restricts the type of data that can be entered in a column. The datatype of a column must match the type of data the column will hold. For example, a column to store employee names should have a character datatype such as Varchar2, a column to store customer numbers should have a numeric datatype such as Number.

Note:	If a column is in a domain, the column datatype (not the domain) is used during generation.

Columns can be defined using the internal datatypes listed in the following table. During generation, datatypes are converted to an equivalent datatype that is appropriate for the target database. Captured datatypes are mapped onto the equivalent internal datatype.  About

Note:	Where a datatype is indicated below as "not Oracle9i", you should not include it in a database definition intended for generation to an Oracle9i database.  If you do, generation will fail, with a message that the datatype is not supported.

Repository datatype	RDBMS	Description
BFILE	Oracle8 database	Stores bitstream or unstructured data streams such as audio, video, picture and binaries. Data in BFILE columns cannot be converted to other large object type datatypes (LOB).
BINARY INTEGER	Oracle	A PL/SQL datatype used to store signed integers.  PL/SQL binary integers can be used in calculations without conversion.
BLOB	Oracle8 database	Stores bitstream or unstructured data streams such as audio, video, picture and binaries. Data in BLOB columns cannot be converted to other large object (LOB) datatypes. BLOB is an internal LOB.
CHAR	Oracle	A fixed-length character string in the range 1 to 255. If a value is entered shorter than the maximum length, the string is blank padded to fit the column length.
CLOB	Oracle8 database	Stores character strings. CLOB is an internal large object (LOB). Data in CLOB columns cannot be converted to other LOB datatypes.
DATE	Oracle	A date ranging from January 1, 4712 BC to December 31, 4712 AD. Fixed at 7 bytes for each row in the table. Default format is a string (such as DD-MON-YY) specified by NLS_DATE_FORMAT parameter.
DECIMAL	Oracle	A sub type of the Number datatype. Stores a fixed point number.
DOUBLE PRECISION	Oracle, ANSI	A sub-type of the Number datatype. Double Precision stores a floating point number with a binary precision in the range 1 to 126. The default is 126.
FLOAT	ANSI	A sub-type of the Number datatype. Float stores a floating point number with a decimal precision 38 or a binary precision in the range 1 to 126.
GRAPHIC	SQL/DS, DB2
IMAGE	N/A	Used for documentation purposes only.
INTEGER	Oracle, ANSI	A sub-type of the Number datatype. Integer stores a positive integer.
LONG	Oracle (not Oracle9i)	A variable-length character string of up to a maximum of 2 gigabytes used for long text strings. Long columns cannot be referenced in materialized view definitions. Restricted use in SQL statements. If the target database is Oracle, only one LONG column can be implemented on a given table. Columns of this datatype cannot be referenced in materialized views or in integrity constraints.
LONG RAW	Oracle (not Oracle9i)	Stores binary data of up to a maximum of 2 gigabytes. Columns of this datatype cannot be used as a primary key.
LONG VARCHAR	SQL/DS, DB2
LONG VARGRAPHIC	SQL/DS, DB2
MLSLABEL	Oracle8 database	Trusted Oracle datatype
NCHAR	Oracle	Stores fixed-length character strings that correspond to a fixed-length or variable-length national character set. The maximum length for an Nchar column is 2000 bytes, or the number of characters that can be stored in 2000 bytes.
NCLOB	Oracle8 database	Stores single-byte or fixed-length multibyte national character set (NCHAR) data. You cannot create an object type with NCLOB attributes, but you can specify NCLOB parameters in a method for an object type.
NUMBER	Oracle, ANSI	A number having a precision and scale, where precision is between 1 and 38, and scale is in the range -84 to 127.
NVARCHAR2	Oracle (not Oracle9i)	Stores variable-length character strings. The maximum length for an Nvarchar2 column is 4000 bytes, or the number of characters that can be stored in 4000 bytes. A maximum size must be specified.
RAW	Oracle	Stores binary data up to a maximum of 255 bytes. A maximum size must be specified.
REAL	Oracle, ANSI	A sub-type of the Number datatype. Real stores a floating point number with a binary precision of 63 or a decimal precision of 18.
ROWID	Oracle	Stores the row identifiers (rowid) assigned to columns in an Oracle database in a readable format. The Rowid datatype enables the unique address of a row in a table to be selected or fetched.
SMALLINT	Oracle, DB2, SQL	A sub type of the Number datatype.
SOUND	N/A	Used for documentation purposes only.
TEXT
TIME	SQL/DS, DB2
TIMESTAMP	SQL/DS, DB2
UROWID	N/A
VARCHAR	Oracle	See Varchar2. It is recommended that you use Varchar2 in preference to Varchar.
VARCHAR2	Oracle	A variable length character string having maximum length between 1 and 4000.  For example, an Address column might have a Varchar2 datatype. A maximum size must be specified.
VARGRAPHIC	SQL/DS, DB2
VIDEO	N/A	Used for documentation purposes only.


Datatype conversions during database generation/capture

Related Topics

During database generation, the repository datatypes are mapped onto an equivalent datatype for the generation target. Conversely, captured datatypes are mapped onto an appropriate repository datatype.

The datatype mappings are listed in the following tables:

•	Datatype conversions when generating database definitions

•	Datatype conversions when capturing definitions from an online database

•	Datatype conversions when capturing definitions from DDL scripts

Tip:	Before printing the above topics, set your printer page orientation to landscape.


Datatype conversions when generating database definitions

Use the following tables to determine the datatype mappings that take place when generating database definitions to your chosen target database. The repository datatypes listed in the outer left column are mapped to their equivalent datatypes shown in the database type columns. For example, a column defined in the repository using a NUMBER datatype is generated as an Rdb NUMERIC column.

•	The Oracle datatype ROWID is always generated as ROWID, since this datatype does not have an equivalent mapping in supported database types.

•	Oracle enforces an implementation constraint that there should not be more than one LONG column in a table e.g. TEXT and VIDEO. It is recommended that more than one potentially LONG column is avoided in a single table definition.

•	The generated scales for BINARY INTEGER, DOUBLE PRECISION, INTEGER, REAL and SMALLINT would appear to be inappropriate for repository datatypes. These particular values have been chosen because they are what is stored by the database manager if these design types are used to create columns.

For more information, see:

−	Datatype mappings for Oracle8, Oracle7 and Oracle Lite databases

−	Datatype mappings for Rdb, ANSI 92, DB2/2, DB2/MVS, SQL Server and Sybase databases

Datatype mappings for Oracle8, Oracle7 and Oracle Lite databases

Datatype mappings for Rdb, ANSI 92, DB2/2, DB2/MVS, SQL Server and Sybase databases


Datatype conversions when capturing definitions from an online database

Use the following tables to determine the datatype mappings that take place when capturing database objects from an online database. The datatypes shown in the source database type columns are mapped onto the repository datatypes listed in the outer left column. For example, a captured Rdb BIGINT datatype is mapped onto the repository INTEGER datatype.

In the following tables, * represents SQL_. So, for example, *VARCHAR in the ANSI92 column reads SQL_VARCHAR

For more information, see:

−	Datatype mappings capturing Oracle8, Oracle7 and Oracle Lite databases

−	Datatype mappings capturing Rdb, ANSI 92, DB2/2, DB2/MVS, SQL Server and Sybase databases

Datatype mappings capturing Oracle8, Oracle7 and Oracle Lite databases

Datatype mappings capturing Rdb, ANSI 92, DB2/2, DB2/MVS, SQL Server and Sybase databases


Datatype conversions when capturing definitions from DDL scripts

Use the following tables to determine the datatype mappings that take place when capturing definitions from a DDL script file. The datatypes shown in the source database type columns are mapped onto the repository datatypes listed in the outer left column. For example, a captured Rdb BIGINT datatype is mapped onto the repository INTEGER datatype.

In the following tables, * represents SQL_. So, for example, *VARCHAR in the ANSI92 column reads SQL_VARCHAR

Note: 	The DB2/2 database conversion from CLOB to LONG VARCHAR is incorrect for CLOB columns greater than 4kB in length. You should modify LONG VARCHAR to TEXT in the column definition in the repository.

For more information, see:

−	Datatype mappings capturing Oracle8, Oracle7 and Oracle Lite databases

−	Datatype mappings capturing Rdb, ANSI 92, DB2/2, DB2/MVS, SQL Server and Sybase databases

Datatype mappings capturing Oracle8, Oracle7 and Oracle Lite databases

Datatype mappings capturing Rdb, ANSI 92, DB2/2, DB2/MVS, SQL Server and Sybase databases


Database types supported by Server Generator

Related Topics

Database object definitions can be generated and captured for the following types of database.

Oracle

Oracle Lite

ANSI 92

Rdb

DB2

SQL Server

Sybase


Database generation - summary of support

Related Topics

This table shows the generation support for the database object types.


Database capture - summary of support

Related Topics

The following table summarizes database capture directly from an online database.

Note:	* For Oracle Lite and Rdb, domain check constraints are captured as check constraints on columns using those domains

The following table summarizes database capture from one or more script files.

The following table summarizes database capture of Oracle8 database objects contained in one or more script files.


Oracle database support

•	Versions of Oracle supported

•	Objects generated for Oracle databases

•	Differences when generating to different versions of the Oracle database

•	Objects captured from Oracle databases

•	Objects captured from Oracle scripts

Versions of Oracle supported

Data definition language commands can be generated and captured for the following versions of the Oracle database.

•	Oracle8.1

•	Oracle8

•	Oracle7

•	Personal Oracle7.3.4

•	Oracle6 (capture from file only)

Note:	Oracle7.3 database and Personal Oracle7.3.4 are equivalent versions.

Objects generated for Oracle databases

DDL commands to create and alter objects can be generated to all supported versions of the Oracle database. DDL commands to create objects only can be generated to file.

DDL command	Database?	DDL script?	Notes:
CREATE TABLE	Y	Y	Generated to create relational tables and object tables.
ALTER TABLE	Y (note 1)	Y	Generated to create primary key, foreign key, unique key and check constraints only. If the constraint already exists on the database, a DROP script will be generated to drop the constraint before it can be recreated.
CREATE INDEX	Y (note 2)	Y	If the index already exists on the target database, a DROP script is generated to drop the index before it can be recreated.
CREATE VIEW	Y	Y	Generated to create relational views and object views.
CREATE SYNONYM	Y	Y	Generated for tables owned by the connected user only.
CREATE CLUSTER	Y	Y
CREATE SEQUENCE	Y	Y	No DDL is generated to support column references to sequences.
CREATE MATERIALIZED VIEW	Y	Y
CREATE TYPE	Y	Y	Generated to create Oracle collection types and Oracle object types.
CREATE TRIGGER	Y	Y
CREATE PACKAGE	Y	Y
CREATE PACKAGE BODY
CREATE PROCEDURE	Y	Y
CREATE FUNCTION	Y	Y
CREATE DATABASE	--	Y
CREATE TABLESPACE	--	Y
CREATE ROLLBACK SEGMENT	--	Y
GRANT	--	Y	Grants system privileges and object privileges.
CREATE USER	--	Y
CREATE ROLE	--	Y
Advanced queuing objects

Code to create/alter advanced queuing objects on a database contains calls to the Advanced Queuing API, rather than DDL statements.

Command	Database?	DDL script?	Notes:
DBMS_AQADM. CREATE_QUEUE	Y	Y
DBMS_AQADM. CREATE_QUEUE_TABLE	Y	Y
DBMS_AQADM. ADD_SUBSCRIBER	Y	Y
Differences when generating to different versions of Oracle

		Oracle version
DDL clause	Repository definition	8	7
PARALLEL clause  (CREATE TABLE, CREATE INDEX, constraints)	Table, Index or Cluster definition, Parallel = Yes	Y	Y
HASH IS clause  (CREATE CLUSTER)	Cluster definition: Hash property = Yes	Y	Y
CACHE clause  (CREATE TABLE)	Table definition: Cache? = Yes	Y	Y
Bitmapped index (CREATE INDEX)	Index definition: /? = Yes	Y	Y
ENABLE/DISABLE clause (CREATE/ ALTER TRIGGER)	Trigger definition: Enable? property	Y	Y
DATAFILE AUTOEXTEND  (CREATE DATABASE, CREATE TABLESPACE)	Database and Tablespace definition: AutoExtend = Yes	Y	Y
Index-only table  (CREATE TABLE)	Table definition: Index-Only? = Yes	Y	--
Partitioning tables / indexes (CREATE TABLE, CREATE INDEX)	Table and Index definitions: Partition = Yes	Y	--
 Objects captured from Oracle databases

Type of Database 0bject	Notes
Table	See About captured relational tables
Primary key	Primary key columns are captured as NOT NULL (mandatory). See About captured constraints
Foreign key	See About captured constraints
Unique key	See About captured constraints
Check constraint	See About captured constraints
Index	See About captured indexes
View	See About captured relational views
Trigger	See About captured triggers
Sequence	The sequence definition only is captured. If the sequence is referenced by columns on a table, the column references are not captured. See About captured sequences
Synonym	Synonyms can be captured for tables owned by the connected user only. See About captured synonyms
Tablespace	Captured if the connected user has Database Administrator permissions on the database. Otherwise the tablespace name only is captured.  Note:  The tablespace is captured with only one data file. If the tablespace comprises multiple data files, the first data file located is captured.  See also About captured tablespaces
Cluster	See About captured clusters
Materialized view	See About captured materialized views
Package	See About captured PL/SQL packages, procedures, functions
Procedure	See About captured PL/SQL packages, procedures, functions
Function	See About captured PL/SQL packages, procedures, functions
Oracle Object types	See About captured Oracle Object Types
Object tables	See About captured Object Tables
Object views	See About captured Object Views
Oracle Collection types	See About captured Oracle Collection Types
Partitioned tables	See About captured partitioned tables
Partitioned indexes	See About captured partitioned indexes
Nested Table	See About captured nested tables
Queues	See About captured persistent queues         About captured non-persistent queues
Queue Tables	See About captured queue tables
Queue Subscribers	See About captured queue subscribers
 Objects captured from Oracle scripts

Command	Oracle7/8 database	Oracle6	Syntax that cannot be captured
CREATE TYPE	Oracle8 database	N
CREATE TABLE	Y	Y	The following syntax is not captured. The schema name of the table. ENABLE|DISABLE clause
ALTER TABLE	Y	Y	ALLOCATE EXTENT clause ENABLE|DISABLE clause
CREATE VIEW	Y	Y	REPLACE option in CREATE OR REPLACE VIEW WITH CHECK OPTION FORCE/NO FORCE keyword
ALTER VIEW	Y	--
CREATE INDEX	Y	Y	The schema name of the index. column ASC|DESC  NOSORT keyword CAPTUREABLE|UNCAPTUREABLE clause
ALTER INDEX	Y	Y	The schema name of the index.
COMMENT ON	Y	Y
CREATE SEQUENCE	Y	Y
ALTER SEQUENCE	Y	Y
CREATE SYNONYM	Y	Y
CREATE TRIGGER	Y	--
ALTER TRIGGER	Y	--
CREATE TABLESPACE	Y	Y
ALTER TABLESPACE	Y	Y
CREATE PACKAGE	Y
CREATE PACKAGE BODY	Y
CREATE FUNCTION	Y
CREATE PROCEDURE	Y
CREATE CLUSTER	Y


Oracle Lite support

Allows you to capture and generate definitions from an Oracle Lite database. You need to connect using the ODBC driver supplied with Oracle Lite.

Versions of Oracle Lite supported

Objects generated for Oracle Lite

Objects captured from Oracle Lite

Versions of Oracle Lite supported

Data definition language commands can be generated and captured for the following versions of the Oracle Lite database:

•	Oracle Lite 3.6 on Windows 95, 98, and NT 4.00

•	Oracle Lite 4.0 on Windows 95, 98, and NT 4.00

Objects generated for Oracle Lite

DDL commands to create and alter objects can be generated to all supported versions of the Oracle Lite database. DDL commands to create objects only can be generated to file.

DDL command	Database?	DDL script?	Notes:
CREATE TABLE	Y	Y	Generated to create relational tables and object tables.
ALTER TABLE	Y (Note1)	Y	Generated to create primary key, foreign key, unique key and check constraints only. Note1: If the constraint already exists on the database, a DROP script will be generated to drop the constraint before it can be recreated.
CREATE VIEW	Y	Y	Generated to create relational views and object views.
CREATE SYNONYM	Y	Y	Generated for tables owned by the connected user only.
CREATE SEQUENCE	Y	Y	No DDL is generated to support column references to sequences.
Objects captured from Oracle Lite

Type of Database 0bject	Notes
Table	See About captured relational tables
Object tables	See About captured object Tables
View	See About captured relational views
Object views	See About captured object Views
Sequence	The sequence definition only is captured. If the sequence is referenced by columns on a table, the column references are not captured. See About captured sequences
Synonym	Synonyms can be captured for tables owned by the connected user only. See About captured synonyms
Materialized view	See About captured materialized views  Note: Oracle Lite does not support the capture of materialized views from file.


ANSI-compliant database support

•	Objects generated for ANSI databases

•	Objects captured from ANSI databases

•	Objects captured from ANSI scripts

This section describes the ANSI commands that can be generated for a database whose type is not explicitly supported. The types of object that can be captured from a database depends on the functionality provided by the ODBC driver used to access it.

Note:	An ODBC driver that supports Level 2 functionality is required to capture primary key and foreign key constraints.

Objects generated for ANSI databases

DDL command	Database?	DDL script?	Notes
CREATE TABLE	Y	Y	Primary key, unique key, foreign key and check constraints can be generated on tables if the target database supports the ALTER TABLE command.
CREATE VIEW	Y	Y	--
Objects captured from ANSI databases

Object type	ODBC Version 1	ODBC Version 2	Notes
	Level 1	Level 2	Level 2
Table	Name, Columns, Comments	—	—	—
Primary key	—	Parent table, Columns	Name	—
Foreign key	—	Parent table, Columns Referenced table,  Referenced columns	Name, Referenced columns	—
Index	Parent table, Name, Columns	—	—	Index objects that relate to constraints might be captured without the constraint.
 Objects captured from ANSI scripts

DDL command	Exceptions
CREATE TABLE	The following syntax cannot be captured. The database name and owner of the table. CREATE [ {GLOBAL|LOCAL} TEMPORARY ] TABLE.  [ ON COMMIT { DELETE | PRESERVE } ROWS ] Collate clause in columns. MATCH <match type> clause in foreign keys. NO ACTION clause in foreign keys. NOT DEFERRABLE option in constraints. INITIALLY DEFERRED in constraints
ALTER TABLE
CREATE VIEW	WITH [CASCADED | LOCAL]
CREATE INDEX	The schema name of the index. column ASC|DESC  ON CLUSTER clause NOSORT keyword CAPTUREABLE|UNCAPTUREABLE clause Note: The CREATE INDEX and ALTER INDEX commands are not supported by ANSI SQL. However, you may capture the Oracle syntax for these commands.
ALTER INDEX	The schema name of the index.
COMMENT ON


Rdb database support

•	Versions of Rdb supported

•	Objects generated for Rdb databases

•	Objects captured from Rdb databases

•	Objects captured from Rdb scripts

Versions of Rdb supported

Data definition language commands can be generated and captured for the following versions of Rdb.

•	Rdb Version 7.0

•	Rdb Version 6.1

Objects generated for Rdb databases

DDL command	Database?	DDL script?	Notes
CREATE TABLE	Y	Y	Column default values that include dates and times are not generated.
ALTER TABLE	Y	Y	All constraints are generated as ‘Deferrable’. This is the default behavior for constraints in Rdb and cannot be controlled by Server Generator.
CREATE INDEX	Y	Y
CREATE VIEW	Y	Y
CREATE DOMAIN	Y	Y	Domain default values that include dates and times are not generated.
ALTER DOMAIN	Y	Y
Objects captured from Rdb databases

Object type	Captured items	Notes
Table	Name, Columns, Comments	Column defined as COMPUTED BY are not captured.
Primary key	Name, Parent table, Columns
Foreign key	Name, Parent table, Columns, Referenced table, Referenced column	Rdb has a large limit of 128 on the number of columns in a constraint. However, it is recommended that you capture foreign keys with fewer than 24 key columns, to maintain performance during design capture.
Unique key	Name, Parent table, Columns
Check constraint	Name, Parent table, Columns, Condition
View	Name, Columns, Comments, SQL Text
Index	Name, Parent table, Columns
Domain (User-defined type)	Name, Datatype, Scale, Precision, Default values, Comments	Default values consisting of dates and times are not captured.
Objects captured from Rdb scripts

DDL commands	Exceptions
CREATE TABLE	The following syntax is not captured. The database name and owner of the table. CREATE TABLE <table_name> FROM <path> STORED NAME IS clause COMPUTED BY clause COLLATING SEQUENCE IS clause SQL clause DTR clause NOT DEFERABLE option in constraints
ALTER TABLE	DROP clause Columns
CREATE VIEW	Stored name View columns SQL clause DTR clause
CREATE INDEX	Stored name ASCending and DESCending columns SIZE IS <int>clause MAPPING VALUES <low>TO<high> TYPE IS HASHED|SORTED clause ENABLE|DISABLE COMPRESSION clause STORE IN <area_name>
ALTER INDEX	Maintenance is disabled Node size Percent fill Usage update/query STORE IN <area_name> clause
CREATE DOMAIN	CREATE DOMAIN <name> FROM <path> Stored name Collating sequence/No collating sequence Domain constraints SQL clause DTR clause
ALTER DOMAIN	Collating sequence / No collating sequence Domain constraint SQL clause DTR clause


DB2 database support

•	Versions of DB2 supported

•	Objects generated for DB2 databases

•	Objects captured from DB2 databases

•	Objects captured from DB2 scripts

Versions of DB2 supported

Data definition language commands can be generated and captured for the following versions of DB2.

•	DB2/2

•	DB2/MVS v 5.1, 4.1

Note:	DB2 databases on host platforms DB2/VSE and DB2/AS400 are not supported.

You must have the SELECT privilege granted on the following DB2 system catalogue tables before capturing from DB2/MVS:

SYSIBM.SYSKEYS

SYSIBM.SYSINDEXES

SYSIBM.SYSFOREIGNKEYS

SYSIBM.SYSRELS

SYSIBM.SYSVIEWS

SYSIBM.SYSCHECKS

SYSIBM.SYSCOLUMNS

Note:  Your DB2 ODBC connection username must be specified in upper case, otherwise Oracle Designer may not be able to perform data definition language capture or generation.

Objects generated for DB2 databases

DDL command	Database?	DDL script?	Notes
CREATE TABLE	Y	Y
ALTER TABLE	Y	Y	Generated to create primary key, unique key, foreign key and check constraints. Unique keys are generated as DB2 unique indexes.
CREATE VIEW	Y	Y
CREATE DOMAIN	Y	Y	Domains are generated as DB2 distinct types. Not supported for DB2/MVS v 5.1, 4.1
CREATE INDEX	Y	Y
For DB2/MVS, allowable value constraints are not generated due to the 8 character naming restriction.

However, allowable value constraints are generated for DB2/2 WorkBench where the limit is 18 characters. The names of these generated constraints are prefixed with AV.

 Objects captured from DB2 databases

Object type	Captured item	Notes
Table	Name,  Columns,  Comments, Tablespace name
Primary key	Name, Parent table, Columns
Foreign key	Name, Parent table,  Columns,  Referenced table,  Referenced columns
Unique key	Name, Parent table Columns	DB2 unique indexes are captured as unique keys.
Check constraint	Name, Parent table, Columns, Condition
Index	Name, Parent table,  Columns, Tablespace name	The WHERE NOT NULL clause on unique indexes is ignored. Such indexes are treated as unique. The 'TYPE ' of index is ignored (i.e. TYPE 1 or TYPE 2 cannot be specified or recovered).
View	Name,  Columns,  Comments, SQL Text	Views created using common table expressions are not captured.
Tablespace	Name, Comments	The name of the tablespace and any comments on that tablespace only are captured.
Domain  (distinct type)	Name, Datatype, Scale, Precision, Default values, Comments	DB2 distinct types are captured as domains.
Objects captured from DB2 scripts

DDL command	Exceptions
CREATE TABLE	The following syntax is not captured. The database name and owner of the table. DATA CAPTURE clause Tablespace options LOB options clause - columns defined as [NOT]LOGGED and [NOT]COMPACT ON DELETE NO ACTION in foreign key REFERENCING clause is captured as ON DELETE RESTRICT
ALTER TABLE	DROP clause DATA CAPTURE clause LOB options clause - columns defined as [NOT]LOGGED and [NOT]COMPACT
CREATE VIEW	Common table expression WITH CASCADED|LOCAL CHECK OPTION clause
ALTER VIEW
CREATE INDEX	The WHERE NOT NULL clause on unique indexes is ignored. Such indexes are treated as unique. The 'TYPE ' of index is ignored (i.e. TYPE 1 or TYPE 2 cannot be specified or recovered).
CREATE DOMAIN
COMMENT ON	Comments on constraints


SQL Server database support

•	Versions of SQL Server supported

•	Objects generated for SQL Server databases

•	Objects captured from SQL Server databases

•	Objects captured from SQL Server scripts

Versions of SQL Server supported

Data definition language commands can be generated and captured for the following versions of Microsoft SQL Server:

•	SQL Server Version 7.0

•	SQL Server Version 6.5

•	SQL Server Version 6.0

Objects generated for SQL Server databases

DDL command	Database?	DDL script?	Notes
CREATE TABLE	Y	Y
ALTER TABLE	Y	Y	Generated to create primary key, unique key, foreign key and check constraints.
CREATE INDEX	Y	Y
ALTER INDEX		Y
CREATE VIEW	Y	Y
ALTER VIEW	Y	Y
CREATE DOMAIN	Y	Y
Objects captured from SQL Server databases

Note:	The database must be owned by the connected user. Rules and default values are not captured.

Object type	ODBC Version 1	ODBC Version 2	Notes
	Level 1	Level 2	Level 2
Table	Name, Columns, Comments	—	—	Columns default to NOT NULL in SQL Server, whereas Server Generator defaults columns to NULL. This means that a column definition may be captured with a mandatory state that does not match the original database structure.
Primary key	—	Parent table, Columns	Name	—
Unique key	—	Parent table, Columns	Name	—
Foreign key	—	Parent table, Columns, Referenced table, Referenced columns	Name,  Target constraint	—
Check constraint	—	Parent table, Columns	Name	—
View	Name, Columns, SQL text	—	—	—
Index	Parent table, Name, Columns	—	—	Index objects that relate to constraints might be captured without the constraint.
Domain	Name
Objects captured from SQL Server scripts

DDL command	Exceptions
CREATE TABLE	The following syntax is not captured. The database name and owner of the table. For example CREATE TABLE [database.[owner].]table_name ON segment_name clause in tables and constraints Temporary tables. For example CREATE TABLE #[#] table_name IDENTITY clause of columns CLUSTERED and NONCLUSTERED in primary keys DEFAULT constraint NOT FOR REPLICATION in check constraints
ALTER TABLE	WITH NOCHECK option WITH FILLFACTOR option
CREATE VIEW	WITH ENCRYPTION option
CREATE INDEX	CLUSTERED and NONCLUSTERED WITH FILLFACTOR IGNORE_DUP_KEY SORT_DATA and SORTED_DATA_REORG IGNORE_DUP_ROW and ALLOW_DUP_ROW ON segment_name clause
ALTER INDEX
CREATE DOMAIN


Sybase database support

•	Versions of Sybase supported

•	Objects generated for Sybase databases

•	Objects captured from Sybase databases

Versions of Sybase supported

Data definition language commands can be generated and captured for the following versions of Sybase:

•	Sybase System 11

Objects generated for Sybase databases

DDL command	Database?	DDL script?	Notes:
CREATE TABLE	Y	Y	Primary key, unique keys, foreign keys and check constraints are generated declaratively.
CREATE INDEX	Y	Y
CREATE VIEW	Y	Y
CREATE DOMAIN
Objects captured from Sybase databases

Object type	Database?	DDL script?	Notes:
Table	Y	CREATE TABLE, ALTER TABLE	Captures primary keys, unique keys, foreign keys and check constraints.
Index	Y	CREATE INDEX, ALTER INDEX
View	Y	CREATE VIEW


About database design

Approaches to database design

Planning the database structure

About data integrity

About referential integrity

About defining base objects


Recording the basic database design

Creating table definitions

Defining columns

Creating domains

Editing table and column definitions

Defining allowable values

Defining integrity constraints


Approaches to database design

Related Topics

Oracle Designer supports different approaches to recording the database design in the repository. The approach you choose will depend on whether your design strategy is based on a top-down analysis of the system, on a rapid development approach or on legacy development.

The different approaches to database design are illustrated below:

Design approach:	Use this tool:
Analysis	Database Design Transformer You can run the Transformer from the Entity Relationship Diagrammer. The Transformer creates table and foreign key definitions from the entities and relationships in your entity model.  About
New Design	Design Editor To work with the design graphically, use Server Model Diagrams.  About If you are new to Oracle Designer, you can use the Server Model Guide to step through the major tasks involved in creating a new relational database design.  About  Alternatively you can create a new Oracle8 database object-relational design using the Server Modeler.  About
Design Capture	Design Editor. You can extract repository definitions from objects on an online database or DDL script. You can refine the definitions in the repository and then generate them to a database or file.  About


Generating a default design from analysis data

You can generate a database design based on the definition of an entity model recorded in the repository. When you have analyzed the requirements of the system in terms of entities and relationships, you can use the Database Design Transformer to convert entities into equivalent table definitions. You can examine these definitions in the repository and add your own refinements before generating the database design to a database or script file.


Refining the default database design

Where am I?

The database design transformed from the entity model will consist of definitions of tables, columns, primary keys and indexes. Although this design is a normalized one, with no repeating data, you should regard it as a first-cut definition of the database that will be refined and tuned.

The first step to implementing the design is to examine the definitions to ensure that the design meets your requirements.

Tip:  Create a Server Model Diagram to work with the design graphically.

How

Examine table definitions	Edit the table definitions to ensure that the columns and constraints generated by the Database Design Transformer meet your requirements. Note: The Database Design Transformer generates unique names for tables from the entity definition. If, when you run the Transformer, a table already exists with the same name as the plural name of the entity, the table name is appended with a numeric suffix to make it unique. This could result in a table called DEPARTMENTS1 and a table called DEPARTMENTS in the same application system. You may want to rename such table definitions before generating the tables on the database.
Examine intersection tables	An intersection table is created to implement many-to-many relationships. You may want to examine the name, columns and primary key definitions of the intersection table to ensure that they meet your requirements.
Update allowable values generated for discriminator columns	When entity sub-types are implemented as a single table, a discriminator column is generated that has allowable values for each sub-type. The valid values are derived from the first three characters of the entity sub-type name. You may want to update the allowable values to more accurately reflect your system design. How
Define check constraints for arc implementations	When entity sub-types are implemented in an arc, foreign key constraints are defined on the parent table that reference values in the sub-type tables.  You can define a check constraint on the parent table to ensure that a value is provided for only one of the foreign key columns during an insert or update. The foreign key constraint is used to validate that the value provided exists in the referenced table.
Examine surrogate primary keys	A surrogate primary key column <table_name>_ID is generated when no unique identifier exists for an entity. You may want to examine the primary key definition to ensure that the name and datatype reflect your system design.
Decide when constraints should be enforced	The foreign key constraints generated to implement relationships have RESTRICTED ON DELETE and ON UPDATE  rules. You can also specify CASCADE, NULLIFY and DEFAULTED rules.
Examine sequence definitions	An Oracle sequence definition <table_name>SEQ is generated for surrogate primary keys.
Next step?

(Optional)  Enhance the database design

Prepare the design for generation


Generating a database from a new relational design

A simple database design will typically consist of a set of table definitions and integrity constraints. When your design is recorded in the repository, you can add enhancements such as storage details, tailor the design for a specific user and design distributed objects.

Tip: 	If you are new to Oracle Designer, you can use the Server Model Guide to help you create your database design.

You can create a detailed database design by stepping through each task in the diagram below. Alternatively, you can quickly create a simple design with many defaults provided for you.  Quick steps


Defining default column values

If a column is mandatory and typically requires a particular value, you can define this value as a default against the column.

When a value for the column is not explicitly provided during an insert or update, the column can be populated with its default value either on the client, via generated Table API procedures, or by the database if a default value is specified for the column.  About

To define a default value for a column:

1.	Double-click the column for which the default value is to be defined.

2.	In the column Default Value property, enter the value to be used as the default.

3.	Specify the Default Value Type.

See Example - Defining default values for more information.

4.	Save the changes.


Example - Defining default values

Column Datatype	Default  Value	Default  Value Type	Generated  DDL
Numeric	100	Literal	DEFAULT 100
Numeric	GetNumber()	Database Function Call	DEFAULT GetNumber()
Date	01-01-2000	Literal	DEFAULT '01-01-2000'
Date	sysdate	Database Function Call	DEFAULT sysdate
Date	"CalcDate()"	Client Function Call
Character	Not Known	Literal	DEFAULT 'Not Known'
Character	'Not Known'	Literal	DEFAULT '''Not Known'''
Character	Martha's Vineyard	Literal	DEFAULT 'Martha''s Vineyard'
Character	'_ _ _'	Literal	DEFAULT '''_ _ _'''
Character	‘_ _ _’	Database Function Call	DEFAULT ‘_ _ _‘
Character	user	Database Function Call	DEFAULT user
Note:	_  denotes a blank space.
DDL generation

During DDL generation, the default value is enclosed in single quotes ( ' ) if the Default Value Type is set to Literal and the datatype is such that literal default values require quotes, e.g. characters, dates, etc.

If the default value entered is a database function, set the Default Value Type to Database Function Call so that single quotes are not generated.

Literal default values containing character strings that are to be displayed in quotation marks, should be entered in single quotes. Similarly, literal default values that consist entirely of blank spaces, or start/end with blank spaces should be entered in single quotes and in addition the Default Value Type property should be set to Database Function Call so that the blank spaces are preserved. Otherwise, quotation marks are not required.

If the default value entered is a client-side function, set the Default Value Type to Client Function Call so that the default value is not generated.

Note: 	The DDL generation principles described here for column default values also apply when generating default values for other database objects, i.e. Domains, Allowable Values, Attributes of Oracle Object Types, PL/SQL Definition Arguments, PL/SQL Definition Program Data and PL/SQL Definition Datastructure Items. Note however, client-side functions are only applicable when defining default values for columns and domains.


Defining uppercase column values
Defining uppercase-only columns

You can define a column as uppercase only to force the values held in the column to uppercase on the database. Records inserted or updated in the column can be converted to uppercase either on the client or via generated Table API procedures.

About

To define uppercase-only columns:

1.	In the Design Editor, edit the column to be defined as uppercase only.

2.	Set the column Uppercase? property to Yes.


Deciding where constraints should be enforced
Deciding where constraint validation should be enforced

Use the following table as a guide to determine where to enforce integrity constraints. By default, most constraints are validated on the server only. However, you can specify validation on both the server and the client, or on the client only.

You specify constraint validation by setting the constraint Validate In? property.

Validate In?	Suitable for:	Benefits
Server	Primary key, unique key, foreign key and check constraints. Foreign key Update and Delete rules: • Restricted • Cascade • Nullify • Defaulted Note: You must generate the Server API to enforce Nullify and Defaulted update and delete rules on the server. How  Column and domain valid values (Column Dynamic List property = No)	Declarative constraints on the server provide centralized business rules that are defined only once as part of the table structure, as opposed to once for each application.  Server-side validation provides a way of guaranteeing data integrity if multiple applications access the table data.
Both	Foreign key Delete and Update rules: • Nullify • Defaulted Column and domain valid values (Column Dynamic List property =Yes) Note: You must generate the Server API to enforce Nullify and Defaulted rules on the server.	Data integrity constraints are enforced on the server.  In addition, Server API validation provides more immediate user-feedback to the client and prevents unnecessary processing on the server.
Client	Foreign key Delete and Update rules: • Nullify • Defaulted	Provides more immediate user-feedback to the client. Prevents unnecessary processing on the server.


Validation code to enforce allowable values (server-side)

Related Topics

When you define allowable values against a column or domain definition, Server Generator generates code to enforce those value restrictions on the database.

There are two ways you can enforce allowable values on the database:

•	using valid value check constraints

•	using a reference code table

Validation against check constraints (hard-coded)

By default, the Server Generator generates a declarative check constraint to enforce allowable values and value ranges. Valid value check constraints are generated when the column Validation property Dynamic List? = No.  About

This type of validation ensures that centralized business  rules are enforced on the database, that are independent of any application that inserts or updates records in the column.

Validation against a reference code table (soft-coded)

Alternatively, allowable values can be loaded into a reference code table. The reference code table is populated for columns (or domains) which have the Validation property Dynamic List? = Yes.  About

The values held in the reference code table can be queried by generated applications to provide dynamic lists of selectable values and to perform data validation. If the application calls generated Table API procedures to perform inserts and updates, validation is performed by Table API procedures and triggers.  About


Using sequences to generate unique values for numeric columns

Where am I?

When you associate a column with a sequence of either type, you can determine whether the sequence value is to be derived on the server, or using client-side code.

To generate unique values for numeric columns:

1.	In the Design Editor, choose Options→Use Property Dialogs.

2.	In the Navigator, select the Server Model tab.

3. 	Create a sequence definition. How

4.	Associate the numeric column with the sequence definition.

−	Double-click the column

−	In the Property Palette, select the name of the sequence from the Sequence field.

5.	Specify whether sequence values will be derived on the server or on the client, by setting the column Server Derived? property, using the table below as a guide.

Sequence values derived on:	Column Server Derived property	Explanation
Server	Server Derived = Yes	The column values can be populated using generated Table API procedures, if no value is provided by the calling application.  About
Client	Server Derived = No  (the default)	The column values are populated using generated client-side code.
6. 	Save the changes.

To specify autogenerated sequence numbers unique within a parent:

1.	Set the AutoGen Type property of the repository definition of the column that will contain the unique sequence numbers to Seq in Parent.

2.	Set the column definition's Server Derived property to specify whether the sequence values will be derived on the server or on the client, using the table below as a guide.

Generate values on the Server, via Table API code	Generate values on the client
Server Derived = Yes	Server Derived = No (the default)
The column values are populated using generated Table API procedures, if no value is provided by the calling application.	The column values are populated using client-side code generated when you generate application modules.
Next step?

Generate the Table API for Oracle Forms and Web PL/SQL applications, if unique values are to be derived on the server. How

Having run Server Generator, you might subsequently change a code control sequence definition or associate another column with a code control sequence. In this case, run the Generate Reference Code Tables utility to manually update the code controls table.


Generating change history columns using Server Generator
Generating change history columns

Where am I?

You can specify that change history information is to be recorded for a column when a row in a table is inserted or updated on the database. The following types of information can be generated for a column:

•	user that created the record

•	date on which the record was created

•	date on which the record was modified

•	user that modified the record

•	next unique number within the referenced primary key, when a new record is created

Change history columns can be populated either on the server, via the Table API, or on the client.

To generate change history information for a column:

1.	In the Design Editor, create a new column in which to record change history information. How

2. 	From the AutoGen Type drop-down list, select the type of change history information required. How

Note: 	Use the appropriate option on the General Generator Options dialog to specify whether to record the time as part of the Date Created and Date Modified information.

3.	Specify whether the change history information is to be generated on the server or on the client:

•	Set the Server Derived property to Yes, to populate the column using generated Table API procedures  About

•	Set the Server Derived property to No if the column is to be populated on the client.

As a column can only contain one type of change history information, a new column will need to be created for each type of change history you want to record.

Note:	Define columns of AutoGen type Modified By or Date Modified as optional In the Column Property palette.


About referential integrity

Referential integrity describes the business rules that determine what action is taken on the server when a row in a table is inserted, updated or deleted. Referential integrity is enforced using foreign key constraints. These rules specify:

•	that values entered into a column must already exist in another column, or else can be NULL

•	what action is taken on the dependent row when a row is deleted or updated in the referenced row

Types of referential integrity

Most types of referential integrity constraints can be enforced declaratively as part of the table structure. Constraints that are defined on tables are always enforced on the database, unless the constraint is disabled or removed.

Referential integrity delete and update rules determine what action is taken if a row in a joined table is deleted or updated.

Example

By default, the record in the primary key table cannot be deleted if a corresponding foreign key value exists. For example, a customer cannot be deleted from the CUSTOMERS table if a RENTAL to that customer is current. You can specify what actions are to be taken when a row is deleted or updated in a table.

Delete Rules:

Restricted:	(default). Declarative constraints enforced on the Server
Cascade:	Declarative constraints enforced on the Server
Defaulted:	Not enforced by default on Oracle database. Can be enforced using Server API or using client-side code
Nullify:	Not enforced by default on Oracle database. Can be enforced using Server API or using client-side code

Update Rules:

Restricted:	(default). Declarative constraints enforced on the Server
Cascade:
Nullify:	Not enforced by default on Oracle database. Can be enforced using Server API or using client-side code
Defaulted:	Not enforced by default on Oracle database. Can be enforced using Server API or using client-side code
Note: 	Referential integrity for referential actions not supported by FOREIGN KEY integrity constraints can be enforced using database triggers  About


Preparing the database design for generation

Where am I?

Before generating the database design, step through the following checklist to identify potential omissions in your database design.

Ensuring data integrity	When you specify a domain on a column and set the domain property Dynamic List? to Yes, the CG_REF_CODES table will be used instead of a constraint. Subsequently, during generation you do not get a warning or a message, and no code is generated to ensure the data integrity for the column with the domain.  The data integrity is only ensured if you generate the Table API.  How
Perform quality checks	Run database design reports to identify potential omissions and inconsistencies in your design. How  For example, do all tables have at least one column and a primary key. (A primary key is necessary when generating Server API packages for the table).  About  Are indexed columns unique? An index can be generated provided that no other index exists on the same set of columns.
Support for object types	Check that the objects to be generated are supported in the target database. Some object types are specific to Oracle databases.  See Database generation - summary of support
Access permissions	Do you have sufficient access permissions to create objects on an online database?  Oracle databases: You need database administrator privileges to create the following objects: database, tablespaces, users, roles ...  Other databases:  SQL Server: You must own the database.
Complete ? property	Is the Complete ? property set for each database object to be generated?  Every database object that you wish to be generated must have the Complete? Property set to Yes.
Dependencies between objects	Have you selected the source and referenced objects? To create a foreign key, you must select the source table and the referenced table.  Note: Objects associated with a table, namely indexes and triggers, are automatically selected when the table is selected.
Namespace conflicts	Do the names of the objects you want to generate conflict with the names of existing objects on the database? The names of all objects that share a namespace must be unique across the repository and the target database.


Invoking the Entity Relationship Diagrammer

You can invoke the Entity Relationship Diagrammer via any of the following methods:

•	Click on the Entity Relationship icon in the Oracle Designer Window

•	Select Tools → Entity Relationship Diagrammer from the Process Modeler

•	Select Tools → Entity Relationship Diagrammer from the Dataflow Diagrammer

•	Select Tools → Entity Relationship Diagrammer from the Function Hierarchy Diagrammer

•	Select Tools → Entity Relationship Diagrammer from the Repository Object Navigator


About database design capture

Related Topics

Database design capture is the process of creating or modifying a repository-held server model using information stored in an existing database or DDL script. The captured server model design can be used as the basis for redesigning an existing system and for migrating systems to other target databases.

Why capture an existing database design?

Many existing applications that have little or no formal documentation for the early stages of development, often store valuable data about the business. To capture the business information or where there is a need to develop a system to update or replace or integrate with the existing system, the initial steps would be to determine:

•	where the data is being stored

•	what format the data is in

•	how the data is used by the existing system

•	how the application system fits in with the current business practice

Design capture or 'bottom-up' development describes the process of:

•	deriving the database definitions (i.e. the captured definitions) from the real-world system

•	deriving the existing business model from the captured data

•	analyzing the new business requirement and comparing it with that derived from the existing system

•	redesigning and implementing the new system, if required, to satisfy the new business requirement

The Capture Design of Server Model from Database utility and the Table to Entity Retrofit utility partially automate the design capture process. Repository definitions derived from the elements of an existing system can be used as the basis for system development.

Stages involved in database design capture

Database design capture can involve two distinct stages:

•	Stage One - Design capture

This stage covers capturing database objects.

•	Stage Two - Rationalization

This stage covers further steps required for recreating a business model, rationalizing the top-down business model with the captured data and completing the cross-referencing.

Stage One - Design capture

This stage can include:

•	capturing database objects

•	implementing changes and enhancements

When this stage is complete most of the design capture has been accomplished. The application system, which until this time may not have been controlled or documented, can now be maintained.

Capturing database objects

Capturing database objects involves using the Capture Design of Server Model from Database utility. The captured repository definitions can then be analyzed to identify and isolate:

•	primary, unique and foreign keys

•	sub-type and super-type entity implementations within, or across, one or more tables

•	denormalized data

•	duplicated data

At this stage, the system designers and end users should be consulted to assist in this analysis.

Naming conventions should also be introduced for ease of use at later stages of development. For example, the use of prefixes could be employed to differentiate between one subsystem and another. Care must be taken where synonyms are used for data items that are present in more than one table. For example, 'organization unit id' may be the primary key in one table but may be referred to as 'company id' in a related table.

Implementing changes and enhancements

The repository can now be used to define and implement changes and enhancements to the existing database.

If definitions of new tables or other objects are created in the repository, they can be generated on the existing database, and existing objects altered.

The diagrams below show how the various Server Generator utilities can be used, both for database objects and for DDL files.

Stage Two - Rationalization

This stage is optional, but it will provide a detailed account of the business model. It may include:

•	deriving a set of elementary business functions from definitions using the Function Hierarchy Diagrammer

•	deriving a 'first-cut' entity model from physical database definition tables, using the Table to Entity Retrofit utility

•	rationalizing the top-down business model with the captured data

•	setting up cross-references between the new business level data and the existing system implementation data, using Repository Object Navigator

Table to Entity Retrofit utility

The Table to Entity Retrofit utility should be used to derive a 'first-cut' entity model from the physical database definition tables.

The utility generates entities, attributes, relationships and unique identifiers in the following way:

•	entity definitions are created from table definitions

•	attribute definitions are created from any columns not involved in foreign key constraints

•	relationships are created from the foreign keys of the specified table and the tables which these foreign keys reference

•	primary keys are captured as primary unique identifiers

•	unique key constraints are captured as secondary unique identifiers

The repository definitions created from this process should be examined carefully. For example, tables used for reference purposes may define domains with sets of known values, 'Type' columns may define entity sub-types, etc.

Rationalizing the top-down business model with the captured data

The work carried out in the previous stage to recreate a business model should be compared with the results of the design capture process. At this stage you should rationalize any differences and establish a common set of naming conventions. Then feed the resulting business level function hierarchy and entity relationship diagram back to the users for their comments.

Completing the cross-referencing

Finally, set up the cross-references between the new business level data and the existing system implementation data. You can use the Repository Object Navigator to specify which new entities are implemented by which tables, and which functions are implemented by which definitions. The end product is a completely cross-referenced and fully integrated application that gives you a firm basis for future enhancements.


About automatic column value generation

Generating change history columns


Generate Table API for Definitions dialog box - Target tab

Related Topics

Generates PL/SQL packages, known as table handlers, from selected table definitions in the repository. These table handlers make up the table component of the Server API and provide an easy way for your applications to insert, update, delete and lock data in the database tables.  About

Note:	The target for generation must be an Oracle 7.3 database or above. If a table handler for a particular table already exists on the target database, running this utility will replace it.

Target for Generation options

File

Generates CREATE PACKAGE commands to create table handlers for selected table definitions. A master command file <file_prefix>.SQL is generated that can be run against an Oracle database to create the table handlers on the database. You can execute this script using Oracle SQL*Plus or SQLDBA. How

Database

Creates table handlers directly to an Oracle database, using a Net8 connection.

Username

The name of the user that must be specified to gain access to the database account. If preferred you can specify the full connect string in this field, in the format:<username>/<password>@<database>

For example, to connect to a database HQ8 using the username and password scott, you would enter: scott/scott@HQ8

If you specify the full connect string here, you do not need to complete the Password and Connect fields.

Password

The password required to connect to the database account.

Connect

The database alias required to access the database account. You must ensure that the database alias is specified in the file TNSNAMES.ORA file in your Oracle home directory, usually <oracle_home>\ NET80\ADMIN.

File Prefix

Specifies a name for the generated file, up to a maximum of 237 characters. Names of previously generated files can be selected from the drop-down list.

The file you specify here is the master command file that you need to run to create the table handlers on an Oracle database. This file calls subsidiary files that contain the commands to create the table handlers.

You can run the file using SQL*Plus or SQLDBA.

Directory

Specifies a directory for generated files. The location of previously generated files can be selected from the drop-down list.

If no directory is specified, the file is written to the current working directory, by default <oracle_home>\bin.

If you specify a directory that does not exist, the utility will attempt to create a new directory of that name, when you select Start. If this process is unsuccessful, either specify an alternative directory that does exist, or close this dialog and create the directory manually. You can use the Browse facility to select a different directory or drive.

Stop on error

Specifies whether generation should be terminated if an error is detected. An error occurs when an object selected for generation, cannot be implemented on the target database.

Stop on warning

Specifies whether generation should terminate if a warning is issued during the generation process. For example, if you do not have sufficient access permissions to create or alter PL/SQL packages and procedures. This option is available only if the 	Stop on error option is selected.

Generate Table API Triggers

Generates a set of database triggers for each selected table definition. These triggers are created in addition to the table handlers to provide data validation if an attempt is made to modify a row in the table directly, that is, outside the Table API.

The triggers call the table handlers to insert, update, delete and lock rows in the table.

Note:	Table API triggers are always generated for foreign keys if the Update Rule/Delete Rule is set to Cascade, Nullify or Default, and the Validate In property is set to 'Server' or 'Both'.

Upload generated files to repository

To save generated files in the repository folder mapped to the directory specified in the Destination of generated files field, check this checkbox. If a repository folder is not mapped to the specified directory, the file is not saved in the repository.

For more information about saving generated files in the repository, refer to About storing generated files in the repository after generation.

Start button

To generate table handlers for the selected tables, click Start.


Generate Table API dialog box - Objects tab
Generate Table API for Definitions dialog box - Objects tab

Allows you to choose the table definitions (no user), or table implementations (user-specific) for which table handlers are to be generated.

Don't Generate list box

Displays the table definitions to be excluded from the generation process. Use the directional arrows to include or exclude an object from the list. By default, this list is populated with the tables associated with the current selection in the Design Editor.

Navigator selection	List is populated with
Container	All table definitions in the container.
User	All table definitions for table implementations on this user.
Generate list box

Displays the table definitions for which table handlers are to be generated. By default, this list is populated with the tables associated with the current selection in the Design Editor.

Navigator selection	List is populated with
Selection of relational table definitions	Selected relational tables
Table implementation definition	Table definitions for selected table implementations
Server Model Diagram	Selected tables on the diagram
Table usages	Tables associated with those usages
Directional arrows

 Generate Selection arrow

Moves selected objects to the Generate list box.

 Generate All arrow

Moves all objects of the selected type to the Generate list box.

 Don’t Generate All arrow

Moves all objects of the selected type to the Don't Generate list box.

 Don’t Generate Selection arrow

Moves selected objects to the Don't Generate / list box.

Start button

To generate table handlers for the selected tables, click Start.


Generate Module Component API dialog box - Target tab

Generates PL/SQL packages, known as module handlers, from selected module definitions in the repository. These module handlers form part of the Server API and provide an easy way for your applications to query, insert, update, delete and lock data in the database tables.  About

Before generating the module handler, you must first generate the table handler. How

Note:	The target for generation must be an Oracle7.3 database or above. If a module handler for a particular module component already exists on the target database, running this utility will replace it.

Target for Generation options

File

Generates CREATE PACKAGE commands to create a module handler for selected modules or module components. A master command file <file_prefix>.SQL is generated that can be run against an Oracle database to create the module handlers. You can execute this script using Oracle SQL*Plus or SQLDBA. How

Database

Generates module handlers directly to an Oracle database, using a Net8 connection.

Username

The name of the user that must be specified to gain access to the database account. If preferred you can specify the full connect string in this field, in the format:<username>/<password>@<database>

For example, to connect to a database HQ8 using the username and password scott, you would enter: scott/scott@HQ8

If you specify the full connect string here, you do not need to complete the Password and Connect fields.

Password

The password required to connect to the database account.

Connect

The database alias required to access the database account. You must ensure that the database alias is specified in the file TNSNAMES.ORA file in your Oracle home directory, usually <oracle_home>\ NET80\ADMIN.

File Prefix

Specifies a name for the generated file, up to a maximum of 237 characters. Names of previously generated files can be selected from the drop-down list.

The file you specify here is the master command file that you need to run to create the module handlers on an Oracle database. This file calls subsidiary files that contain the commands to create the module handlers.

You can run the file using SQL*Plus or SQLDBA.

Directory

Specifies a directory for generated files. The location of previously generated files can be selected from the drop-down list.

If no directory is specified, the file is written to the current working directory, by default <oracle_home>\bin.

If you specify a directory that does not exist, the utility will attempt to create a new directory of that name, when you select Start. If this process is unsuccessful, either specify an alternative directory that does exist, or close this dialog and create the directory manually. You can use the Browse facility to select a different directory or drive.

Stop on error

Specifies whether generation should be terminated if an error is detected. An error occurs when an object selected for generation, cannot be implemented on the target database.

Stop on warning

Specifies whether generation should terminate if a warning is issued during the generation process. For example, if you do not have sufficient access permissions to create or alter PL/SQL packages and procedures. This option is available only if the Stop on error option is selected.

Upload generated files to repository

To save generated files in the repository folder mapped to the directory specified in the Destination of generated files field, check this checkbox. If a repository folder is not mapped to the specified directory, the file is not saved in the repository.

For more information about saving generated files in the repository, refer to About storing generated files in the repository after generation.

Start button

To generate module handlers for the selected modules or module components, click Start.


Generate Module Component API dialog box - Objects tab

Related Topics

Allows you to choose the module or module component definitions for which Server module handlers are to be generated.

Don't Generate list box

Lists the module component definitions in the current container that do not require a module handler. By default, this list is populated as follows.

Selection	List is populated with
Module component	Unselected module components
Module diagram	Unselected module components displayed on the diagram
Generate list box

Lists the module component definitions in the current container for which a module handler is to be generated. By default, this list is populated as follows.

Selection	List is populated with
Module component	Selected module components
Module diagram	Selected modules on the diagram
Directional arrows:

 Generate Selection arrow

Moves selected objects to the Generate list box.

 Generate All arrow

Moves all objects of the selected type to the Generate list box.

 Don’t Generate All arrow

Moves all objects of the selected type to the Don't Generate list box.

 Don’t Generate Selection arrow

Moves selected objects to the Don't Generate list box.

Start button

To generate module handlers for the selected modules or module components, click Start.


Alter Index-Based Objects dialog box

This dialog appears during DDL generation when there are index-based objects that do not match the database design and it is possible to drop and recreate ("alter") them. The Server Generator preference DRPSAC must be set to Ask (the default).

Three types of object are handled by this dialog: indexes, constraints and triggers. There is a tab for each one.

[Objects] not to be altered

Displays the names of objects for which drop and recreate statements can be generated.

Single right-pointing button

Moves any objects that you have highlighted in the left pane to the right pane.

Single left-pointing button

Moves any objects that you have highlighted in the right pane to the left pane.

Double right-pointing button

Moves all objects in the left pane to the right pane.

Double left-pointing button

Moves all objects in the right pane to the left pane.

[Objects] to be altered

Drop and recreate statements will be generated for all the objects displayed in this list.

OK button

Continues with DDL generation, including generation of the DDL to drop and recreate the objects listed in the right pane.

Cancel button

Closes the dialog and continues DDL generation without dropping and recreating any of the objects, even if they are in the right pane.

Stop Generation button

Stops the generation of DDL completely.


Drop Database Objects dialog box

This dialog appears during DDL generation when there are objects in the database that are not in the repository and it is possible to drop them, and if the Server Generator preference DRPSAC is set to Ask (the default).

Four types of object are handled by this dialog: columns, constraints, indexes and triggers. There is a tab for each one.

[Objects] not to be dropped

Displays the names of objects (columns, constaints, indexes or triggers, depending on which tab is selected) for which DROP statements can be generated.

If a tab is not available it is because there are no objects of that type to drop.

Single right-pointing button

Moves any objects that you have highlighted in the left pane to the right pane.

Single left-pointing button

Moves any objects that you have highlighted in the right pane to the left pane.

Double right-pointing button

Moves all objects in the left pane to the right pane.

Double left-pointing button

Moves all objects in the right pane to the left pane.

[Objects] to be dropped

DDL DROP statements will be generated for all the objects displayed in this list.

Cascade Constraints (Columns tab only)

Check this box to also drop associated constraints.

Checkpoint (Columns tab only)

You can apply a checkpoint for the drop columns operation to avoid running out of rollback segment space. To apply a checkpoint, enter an integer greater than zero in this box. This will be the number of rows processed after which the checkpoint is applied.

OK button

Continues with DDL generation, including generation of the DDL to drop the objects listed in the right pane.

Cancel button

Closes the dialog and continues DDL generation without dropping any of the objects, even if they are in the right pane.

Stop Generation button

Stops the generation of DDL completely.


Generate Reference Code Tables dialog box - Target tab

Related Topics

Generates reference code tables containing allowable values to a DDL script file, an Oracle database, or another type of database via an ODBC driver. Reference code tables store allowable values defined against column, domain and unbound item definitions in the repository.

Target for Generation

File

Generates a file containing commands to create or alter reference code tables. You can execute this script later, using Oracle SQL*Plus or SQLDBA. How

Database

Creates (and alters) reference code tables directly on an Oracle database, using a Net8 connection.  About

Username

The name of the user that must be specified to gain access to the database account. If preferred you can specify the full connect string in this field, in the format:<username>/<password>@<database>

For example, to connect to a database HQ8 using the username and password scott, you would enter: scott/scott@HQ8

If you specify the full connect string here, you do not need to complete the Password and Connect fields.

Password

The password required to connect to the database account.

Connect

The database alias required to access the database account. You must ensure that the database alias is specified in the file TNSNAMES.ORA file in your Oracle home directory, usually <oracle_home>\ NET80\ADMIN.

ODBC

Creates (and alters) reference code tables directly on databases other than Oracle, via an ODBC data source.

To use this option, you must have installed an ODBC driver for the target database type and set up a data source to the required database. A specific driver is required for each type of database you want to access.

Source

Specifies the name of a predefined data source. If the data source you want is not displayed in the list, cancel this dialog box, then set up a data source to the database you want to access. How

When you connect to an ODBC data source, you will be prompted for logon information. This information will vary depending on the type of ODBC driver you are using.

Note:	You must use a standard Oracle connection, rather than an ODBC driver, when generating to an Oracle database.

Type

Specifies the type and version of your target database.

File Prefix

Specifies a name for the generated file, up to a maximum of 237 characters. Names of previously generated files can be selected from the drop-down list.

You can run the file using SQL*Plus or SQLDBA.

Directory

Specifies a directory for generated files. The location of previously generated files can be selected from the drop-down list.

If no directory is specified, the file is written to the current working directory, by default <oracle_home>\bin.

If you specify a directory that does not exist, the utility will attempt to create a new directory of that name, when you select Start. If this process is unsuccessful, either specify an alternative directory that does exist, or close this dialog and create the directory manually. You can use the Browse facility to select a different directory or drive.

Stop on error

Indicates whether generation will terminate if an error is detected during generation.

Stop on warning

Specifies whether generation will terminate if a warning is detected during generation. For example, if you do not have sufficient access permissions to create PL/SQL packages and procedures. This option is available only if the Stop on error option is selected.

Upload generated files to repository

To save generated files in the repository folder mapped to the directory specified in the Destination of generated files field, check this checkbox. If a repository folder is not mapped to the specified directory, the file is not saved in the repository.

For more information about saving generated files in the repository, refer to About storing generated files in the repository after generation.

Start button

To generate reference code tables, click Start.


Generate Reference Code Tables dialog box - Objects tab

Related Topics

Allows you to choose the database objects to be generated.

Don't Generate list box

Displays tables and modules in the current container to be excluded from the generation process.

Generate list box

Displays the objects that are selected for generation, i.e. tables and/or modules. Use the directional arrows to include or exclude an object from the list. By default, this list is populated as follows.

Navigator selection	List populated with
One or more tables	All selected tables
One or more modules	All selected modules
Diagram selection	List populated with
One or more tables (or modules) on a diagram	All selected tables (or modules)
If no selection is made in the navigator tabs this list will contain no objects.

Directional arrows

 Generate Selection arrow

Moves selected objects to the Generate list box.

 Generate All arrow

Moves all objects of the selected type to the Generate list box.

 Don’t Generate All arrow

Moves all objects of the selected type to the Don't Generate list box.

 Don’t Generate Selection arrow

Moves selected objects to the Don't Generate list box.

Start button

To generate reference code tables, click Start.


About database generation

Related Topics

Database generation involves two distinct stages.

•	First, generate any database administration objects you have defined in the repository

You will need to execute the generated commands using a separate tool. If the target for generation is an Oracle database, you can use SQL*Plus or SQLDBA.

•	Then, generate database objects from a server model to one of the following targets:

−	an Oracle database, using a native Oracle Net8 connection

−	another database, via an ODBC driver

−	a DDL script, that you can run against the target database

Generating database administration objects

Generating database objects

Generating database objects to an online database (Automatic reconciliation)

Generating DDL scripts

Generated files

DROP scripts

Reconcile Reports

Generating database administration objects

The Generate Database Administration Objects utility generates data definition language (DDL) statements to create a database instance and physical database structures from definitions recorded in the repository. You define and generate the following types of object within the context of an existing database and user definition.

•	database

•	database links

•	rollback segments

•	tablespaces

•	replication groups

•	users

•	roles

•	profiles

•	grants

•	system privileges

The commands are written to a series of command files that contain the commands necessary to create the database and database structures. See Generated command files.

Generating database objects

The Generate Database from Server Model utility allows you to create and alter objects directly onto a database. Alternatively, you can generate DDL commands to a set of script files that you can run to create the objects on an existing database.

The following types of object can be generated:

ANSI-compliant	Oracle-specific	Oracle8	Oracle8.1
relational tables	clusters	Oracle object types	Java classes
- constraints	materialized views	Oracle collection types	function-based indexes
- indexes	sequences	object tables	queue tables
relational views	triggers	object views	queues
synonyms	PL/SQL functions,	partitioned tables	queue subscribers
comments	procedures, packages	partitioned indexes
		nested tables
		index-organized tables
Generating database objects to an online database (Automatic reconciliation)

There are two processes that take place when generating repository definitions to an online database.

•	Cross referencing  First, the repository definitions you select for generation are cross referenced against the existing objects on the online database.

Any differences between the repository definition and the online database object are written to a script that contains the commands necessary to create or alter the objects on the database.

A DROP script is generated if there are differences between the definitions of indexes and constraints. You will be asked to confirm whether or not you want these objects to be updated, since the objects must first be dropped before they can be recreated on the database from the repository definitions.

•	Automatic reconciliation  Then, any objects that do not exist on the database will be created and existing objects altered. If an index or constraint must be dropped before it can be recreated, you must first confirm that this is your intention.

The Reconcile Report script is named <File_Prefix>.lis and after generation you have the option to view the file and check through the changes required. You then have the option to execute the changes on the target database.

Note:	Generation can take place only on a single database at any one time.

Generating DDL scripts

You can use the Generate Database from Server Model utility to generate DDL scripts in the flavor of DDL syntax that is appropriate for your target database. When you run the utility, you simply choose the type of syntax you want, specify the name and location of the script, and the utility generates the correct syntax for your chosen target. If the type of database you want is not explicitly supported, you can generate ANSI 92 standard SQL.

You can then use a separate tool to run the script against the database to create the objects. If the target for generation is an Oracle database, you can use SQL*Plus or SQLDBA.

Generated files

When you generate the database design to a file, DDL commands are written to:

•	a master command file (.SQL)

•	a set of database object command files

If the target for generation is an Oracle database, a set of command files is generated for each type of object you select. The generated files are called by a single master command file <File_Prefix>.SQL. You can create the database objects in one step by running the master command file, or you can build the database objects incrementally by running individual command files in the appropriate order.

If the target for generation is another database, a single command file <File_Prefix>.SQL is generated that contains all the DDL statements necessary to create the selected objects. You can run the .SQL file to create the objects on the target database.

Database object	Generated file
Queue Tables	<File_Prefix>.aqt
Persistent Queues	<File_Prefix>.aqp
Non-Persistent Queues	<File_Prefix>.aqn
Queue Subscribers	<File_Prefix>.aqs
Allowable Values	<File_Prefix>.avt	(Reference code tables only)
Code Control Sequences	<File_Prefix>.ccs	(Code control sequences only)
Cluster	<File_Prefix>.cls
Cluster Indexes	<File_Prefix>.cli
Constraints	<File_Prefix>.con
Database	<File_Prefix>.db
Database Links	<File_Prefix>.dbl
Database Directories	<File_Prefix>.dir
Functions	<File_Prefix>.fnc
Indexes	<File_Prefix>.ind
Java classes	<File_Prefix>.jav
Packages	<File_Prefix>.pks
Package body	<File_Prefix>.pkb
Procedures	<File_Prefix>.prc
Profiles	<File_Prefix>.prf
Partitions	<File_Prefix>.ptn	(Alter table, i.e. add new partition or move partition)
Replication Groups	<File_Prefix>.rpg
Replication Objects	<File_Prefix>.rob
Roles	<File_Prefix>.rle
Role/User Grants	<File_Prefix>.grt
Rollback Segments	<File_Prefix>.rbs
Sequences	<File_Prefix>.sqs	(Oracle sequences only)
Materialized Views	<File_Prefix>.snp
Materialized View Logs	<File_Prefix>.snl
Synonyms	<File_Prefix>.syn
Tables	<File_Prefix>.tab	(Relational, object, code control tables, reference code tables)
Tablespaces	<File_Prefix>.tbs
Triggers	<File_Prefix>.trg
Types	<File_Prefix>.typ	(Oracle object types and Oracle collection types)
Type methods	<File_Prefix>.tyb	Oracle object type methods
Users	<File_Prefix>.usr
Views	<File_Prefix>.vw	(Relational and object)
DROP scripts

When generating to an online database, any differences detected between the definitions of indexes and constraints in the repository and the online database definitions are written to a DROP script:

<File_Prefix>.drp

You can execute this script to drop the objects so that they can be recreated on the database.

If a constraint definition that exists on the online database is removed from the repository, a drop statement for the constraint is written to the DROP script.  See Drop Constraints dialog box.

Reconcile Reports

If changes are made to your server model, you will have to generate DDL for all or part of the model again in order to alter the design on the database. If your database is online (Oracle or ODBC), a Reconcile Report (<File_Prefix>.lis ) is generated detailing the objects that need to be created or altered on the database. You can view the Reconcile Report to check through the changes that are required, or implement the changes directly on the target database.

Note:	If you generate DDL to a script file, no cross-referencing/reconciliation can take place.


Running DDL scripts

At the end of generation, you can browse through the DDL script files that the Server Generator has produced. These files contain the commands that will create the database when you execute them.  You can run a generated DDL script directly from the SQL*Plus prompt.

You can build a database incrementally, or in a single step.

Incremental build

Run the DDL scripts one by one to build the database in a controlled fashion. This incremental method of implementing the database is recommended for all but the simplest design because of the interdependencies of the DDL scripts.

When you build the database incrementally, make sure you execute the DDL scripts in a logical order: For example:

•	First, execute the .db file to create the database.

•	Next, execute the .tab file to create database tables.

•	Then, execute the DDL scripts for materialized views, views, PL/SQL, indexes, triggers, etc. All these objects depend on the existence of tables.

If you are not sure the order in which files should be executed, refer to the master command .sql file. This file lists individual script files in the correct order.

One-step build

Select and run the master command .sql file.

This file contains entries to run each of the other script files that Server Generator has produced. Therefore, if you execute this file you will create your database system in a single step.

Implementation

Once you have run the DDL scripts, you will have an implementation of a database that you have defined in the repository. Now you can use the database for Oracle applications, such as generated forms and reports.


Generating the database design

Related Topics

Database generation

About database generation

Validation checks performed during database generation

Database generation - summary of support

Database administration objects

Generating database administration objects

Database objects

Specifying database generation options

Generating objects on an Oracle database

Generating objects on another database

Generating DDL scripts


Generating objects on an Oracle database

Where am I?

You can generate objects directly on an Oracle database using a native Oracle Net8 connection. Alternatively, you can generate DDL scripts. How

Before generating the design, you should have prepared the design for generation.

To generate objects directly on an Oracle database:

1.	Select at least one object definition you want to generate in the Navigator.

−	Select objects on the Server Model view to generate the base object.

About

−	Select objects on the DB Admin view to generate objects tailored for a specific user. About

Note:	You must select an object definition rather than a node in the tree.

2.	Select Generate →Generate Database from Server Model.

Alternatively, click on the Generate DDL button.

3.	On the Target tab, select Database.

4. 	Enter a username, password and connect string to log on to the database schema where the objects will be created, or altered, if they already exist.

5.	In the File Prefix field, enter the name of the script to be generated.

Alternatively, select the name of a file you generated previously from the drop-down list.

6.	[Optional]  In the Directory field, enter the path where the script is to be generated.

You can select the paths used during previous runs of the utility, or you can use the Browse facility to choose a different drive and directory.

Note:	If you omit the path, the script is written to the current working directory.

7. 	Select Stop on error to terminate the generation if an error is detected during generation.

8.	To store all generated files in the repository, check the Upload generated output to Repository checkbox. About

9.	Select the Objects tab.

10.	Choose the objects you want to generate, by moving them to the Generate list box.

11.	(Optional)  Select the Options button to specify your preferred generation options. About

12.	Select Start to begin generation.

During the generation process, progress information is displayed in the Messages Window. If any errors occur, correct the errors and then generate the DDL again. To avoid overwriting existing files, enter a new prefix for these generated files.

Tip:	To display cause and action information, select the message and click

13.	At the end of generation, select Execute DDL.

You can view the generated files or the reconcile report first if you wish.

14.	Review the new Oracle database design.

Next step

If you alter the server model after generation you will have to generate all or part of the database design again. How


Generating objects on other databases

You can generate database object definitions directly on a SQL database, using an ODBC database connection.

Before you can connect to a database via ODBC, you must first:

•	install the ODBC driver appropriate for the DBMS  How

•	set up a data source to the database you want to access  How

You should also ensure the design is prepared for generation

To generate objects on other databases:

1.	Select at least one object definition you want to generate in the Navigator.

−	Select objects on the Server Model view to generate the base object.

About

−	Select objects on the DB Admin view to generate objects tailored for a specific user. About

Note:	You must select an object definition rather than a node in the tree.

2.	Select Generate→Generate Database from Server Model.

Alternatively, click on the Generate DDL button

3.	On the Target tab, select the ODBC option.

4.	Select the name of the data source to gain access to the database.

If no data source is available, cancel this dialog and set up a data source to the database you want to access. How

Note:	By default, Server Generator will attempt to determine the database type from the data source connection. If the Type field is not automatically populated, choose the database type that matches your target database type. Select ODBC if the type you want is not listed.

5.	In the File Prefix field, enter the name of the script to be generated.

Alternatively, select the name of a file you generated previously from the drop-down list.

6.	[Optional]  In the Directory field, enter the path where the script is to be generated.

You can select the paths used during previous runs of the utility, or you can use the Browse facility to choose a different drive and directory.

Note:	If you omit the path, the script is written to the current working directory.

7. 	Select Stop on error to terminate the generation if an error is detected during generation.

8.	To store all generated files in the repository, check the Upload generated output to Repository checkbox. About

9.	Select the Objects tab.

10.	Choose the objects you want to generate, by moving them to the Generate list box.

11.	(Optional)  Select the Options button to specify your preferred generation options.  About

12.	Select Start to begin generation.

During the generation process, progress information is displayed in the Messages Window. If any errors occur, correct the errors and then generate the DDL again. To avoid overwriting existing files, enter a new prefix for these generated files.

Tip:	To display cause and action information, select the message and click

13.	At the end of generation, select Execute DDL.

You can view the generated files or the reconcile report first if you wish.

14.	Review the new database design.

Next step

If you alter the server model after generation you will have to generate all or part of the database design again. How


Generating DDL scripts

You can generate data definition language (DDL) scripts in the syntax appropriate for your target database, based on all or part of your database design. The generated scripts can then be run against the target database using a separate tool.

To generate a DDL script:

1.	Select at least one object definition you want to generate in the Navigator.

−	Select objects on the Server Model view to generate the base object.

About

−	Select objects on the DB Admin view to generate objects tailored for a specific user.  About

Note:	You must select an object definition rather than a node in the tree.

2.	Select Generate→Generate Database from Server Model.

Alternatively, click on the Generate DDL button.

3. 	On the Target tab, select the DDL Files Only option.

4. 	From the Type drop-down list, select the type of DDL syntax to be generated.

If there is no corresponding database type for the target you require, select ANSI 92 to generate ANSI-compliant syntax.

5.	In the File Prefix field, enter the name of the script to be generated.

Alternatively, select the name of a file you generated previously from the drop-down list.

6.	[Optional]  In the Directory field, enter the path where the script is to be generated.

You can select the paths used during previous runs of the utility, or you can use the Browse facility to choose a different drive and directory.

Note:	If you omit the path, the script is written to the current working directory.

7. 	Select Stop on error to terminate the generation if an error is detected during generation.

8.	To store all generated files in the repository, check the Upload generated output to Repository checkbox. About

9.	Select the Objects tab.

10.	Choose the objects you want to generate, by moving them to the Generate list box.

11.	(Optional)  Select the Options button to specify your preferred generation options.  About

12.	Select Start to begin generation.

During the generation process progress, information is displayed in the Messages Window. If any errors occur, correct the errors and then generate the DDL again. To avoid overwriting existing files, enter a new prefix for these files.

Tip:	Use the [image] [image] toolbar buttons to scroll through the error messages. For each message, cause and action information can be displayed and where applicable, navigation options are displayed which allow you to navigate to the source of the error.

13.	To review the content of generated DDL files:

(a) Click [image] on the Messages Window toolbar.

(b) Double-click the file name to view the content.

Next step?

Run the DDL scripts on your target database. How


Specifying database generation options

Where am I?

When you generate database definitions, Server Generator ensures that any associated objects are also generated. You can control this behavior by changing the generation options.

To specify database generation options:

1.	Select Options→Generator Options→Database.

2.	Specify your preferred generation options.

Generation options for ANSI-compliant databases

•	Generating indexes

Generates all indexes defined against the tables, materialized views and clusters selected for generation.

•	Generating constraints: primary key, foreign key, unique key, check constraint

Generates all primary key, unique key, foreign key and check constraints defined against selected tables.

•	Generating comments

Generates any comments defined against the objects selected for generation.

Generation options for Oracle databases

•	Generating triggers

Generates all triggers defined against the tables selected for generation.

•	Generating valid value constraints

Generates a check constraint against columns that have allowable values defined against them, or that are associated with domains with valid values

•	Generating grants

Generates grants defined against the objects selected for generation.

•	Generating synonyms

Generates synonyms defined for the objects selected for generation

•	Generating replication code

Generates statements to replicate objects on a distributed system.


Generating database administration objects

You can generate data definition language (DDL) script files containing statements to create Oracle database administration objects defined in the repository. For example, database definitions, with rollback segments, users, and roles, etc. About

You can then run the generated scripts against the target Oracle database using SQL*Plus.

Note:	No DDL is generated for other databases, as they do not support database administration objects. However, if you have defined user-specific implementations for database objects on other databases the necessary DDL can be generated. How

To generate database administration objects:

1.	Select the DB Admin view.

2.	In the Navigator, select at least one database administration object that is defined against an Oracle database definition.

Tip: 	Select the Oracle Database definition if you want to generate all database administration objects defined for a particular database.

3.	Select Generate→Generate Database Administration Objects.

4.	On the Target tab, enter the following information:

−	a File Prefix (name) for the generated file

−	a directory for the generated file, if different from the current working directory

−	the type of DDL syntax to be generated

−	the database definition from which administration objects are to be generated.

5. 	(Optional)  Specify your preferred generation options.

6.	To store all generated files in the repository, check the Upload generated output to Repository checkbox. About

7.	Select the Objects tab.

8.	Choose the objects you want to generate, by moving them to the Generate list box.

9.	Select Start to begin generation

During the generation process, progress information is displayed in the Messages Window. If any errors occur, correct the errors and then generate DDL for the effected database administration object again. To avoid overwriting existing files, enter a new prefix for these generated files.

Tip:	To display cause and action information, select the message and click

10.	To review the content of generated DDL files:

(a)	Click [image] on the Messages Window toolbar.

(b)	Double-click the file name to view the content.

Next step?

Run the DDL scripts against the target database. How


Validation checks performed during database generation

During generation, Server Generator validates repository definitions selected for generation. An error is reported to trap the following conditions:

•	Table definitions without columns

•	Index definitions without key components

•	Primary keys without key components

•	Unique keys without key components

•	Foreign keys without key components

•	Check constraints without a PL/SQL statement

•	Datastructures without a datastructure item

•	Clusters without cluster columns


Reconcile report preferences

The reconcile report preferences enable the user to choose which objects will be reported on by the reconcile process and in what detail. The options available are defined in the following table:

Difference Detail	Objects Option	Generation Option	Report Level
Definition	Primary Elements and Secondary Elements	No Report	Differences and Sameness
Definition and Implementation	Primary Elements Only	Report and Generation	Only Differences
Implementation		Report Only
Difference Detail

You can specify whether the reconcile report should show differences between the implementation and/or the definition of objects.

Objects Option

You can specify to report on primary and secondary elements, or just the primary elements (PACS), i.e. which PACS are the same and/or different without going into the detail of the differences.

Generation Option

You can specify to just generate a reconcile report without generating the DDL, just generate the DDL or do both.

Report Level

You can specify whether the reconcile report should detail the differences and/or sameness between all objects. The report will detail how columns differ, e.g. datatype differences.


Reconciling repository definitions

Related Topics

There are two processes that take place when generating repository definitions to an online database.

•	Cross referencing  First, the repository definitions you select for generation are cross referenced against the existing objects on the online database.

Any differences between the repository definition and the online database object are written to a script that contains the commands necessary to create or alter the objects on the database.

A DROP script is generated if there are differences between the definitions of indexes and constraints. You will be asked to confirm whether or not you want these objects to be updated, since the objects must first be dropped before they can be recreated on the database from the repository definitions.

•	Automatic reconciliation  Then, any objects that do not exist on the database will be created and existing objects altered. If an index or constraint must be dropped before it can be recreated, you must first confirm that this is your intention.

The Reconcile Report script is named <File_Prefix>.lis and after generation you have the option to view the file and check through the changes required. You then have the option to execute the changes on the target database.

Note:	Generation can take place only on a single database at any one time.


Generating a database from a captured design

Related Topics

You can generate a database based on an existing design, by capturing repository definitions from an existing database or from a data definition language (DDL) script. About

Database capture allows you to:

•	redesign existing systems

•	migrate an existing system to a different target database


Capturing an existing database design

Where am I?

Introduction

About database design capture

What happens during database design capture?

Prerequisites for capturing a database design

Database design capture - summary of support

How to...

Capture objects from an Oracle database

Capture objects from another database

Capture objects from DDL scripts


What happens during database design capture?

During database design capture, Server Generator extracts database definitions from the source database or file and creates equivalent repository definitions. The Capture Server Model facility captures objects within the context of an existing database definition, and for a specific user. Before you can capture objects, a database definition and user specific database object implementation must exist for you to use. You can create database definitions and create user definitions in the Database Administration Objects view.

The Capture Server Model facility creates two distinct views of the objects captured into the repository:

•	User specific database object implementations are created that represent the objects captured from the connected user's schema. User specific database object implementations represent the physical implementation of the objects for that user, and are displayed in the Database Administration Objects view.  About

•	Database object definitions of the user objects are displayed on the Server Model view. The database object definitions represent the logical design of the objects captured into the repository. You can edit the database object definitions to change the design of relational tables, relational views, materialized views, clusters, sequences, PL/SQL definitions, object tables, object views, Oracle object types, Oracle collection types, etc.  About

When you capture an object from a database or file that already exists in the repository, Server Generator reconciles the repository definition with new information extracted from the database or file. The information in the repository is considered to be the reference information. So, only new primary elements, such as tables and new secondary elements, such as columns are added. Properties of existing database objects are never overwritten.

Database capture preferences

You can control many aspects of the database capture process via preferences. Every preference has a default setting that will be used if the preference has not been set explicitly. About


Prerequisites for capturing a database design

Where am I?

Object definitions are captured for a user definition within a specific database instance. Before you can capture a database design, a database definition and user definition must be defined in the repository for you to use. The captured objects are associated with the user and database definition.

You can create database definitions and create user definitions using the Database Designer.

Capturing object definitions from a script

You can capture any DDL script that contains valid SQL CREATE or ALTER statements. For details of the types of command that can be captured from different types of source file, see Database types.

Note: DROP statements are ignored.

Before you capture from a file, make sure that the DDL components in the file meet the following requirements.

SQL command	Requirements for design capture
CREATE TABLE	Must contain at least one column.
	To capture a table constraint, index or trigger, make sure that the file contains the DDL to create the table and the referenced object.
PRIMARY KEY	Must contain at least one column.
FOREIGN KEY	Must contain at least one column. The file must also contain the DDL to create the referenced table.
UNIQUE KEY	Must contain at least one column.
CREATE INDEX	Must contain at least one column.
CREATE TRIGGER	The file must contain the DDL to create the referenced table.
If a command contains references to another object, such as a foreign key reference to a primary key on another table, make sure that the DDL to create the referenced object appears first.

Capturing definitions from an online database

Other databases

You can capture objects from third-party databases via an ODBC database connection. To do this, you must first:

•	install an ODBC driver specific to the target database. How

•	set up a data source to the required database. How

Access permissions

To capture objects from a database, you must own all of the objects to be captured.

Note:	To capture objects from a SQL Server database, you must own the database.

Support for database design capture

You can capture an object from a database provided that it is supported by the design capture process and the conditions for design capture are met. See Database design capture - summary of support for details of which object types can be captured from your chosen target.

You should also note that:

•	Tablespace definitions can be captured from an Oracle database only if you are connected as Database Administrator.

•	DB2 distinct types are captured as domains.

•	DB2 unique indexes are captured as unique key constraints.

Dependencies between objects

The key dependencies to note when capturing objects are as follows:

•	A foreign key can be captured if the source table and referenced table are also captured.

•	An index can be captured if the indexed table is also captured.

•	A trigger can be captured if the referenced table is also captured.

•	A synonym for an object can be captured provided that the object is owned by the connected user.

Capturing large schemas

If the schema you intend to capture contains a large number of tables, consider adjusting the default storage parameters on the repository table RM$DEFERRED_QUERIES so that it has unlimited extents and can grow in larger chunks (say NEXT 100K-500K).


Capturing objects from an Oracle database

Where am I?

A server model can be captured directly from an Oracle database. Before you begin, you should be familiar with the prerequisites for database design capture.  About

At the end of the capture process, the captured objects are displayed in the Navigator. If preferred, captured objects can be viewed graphically on a Server Model Diagram.

To capture a server model from an Oracle database:

1.	Ensure that a database definition and user definition exist for you to use. Database and user definitions are displayed in the Database Administration view in the Navigator. If not, first:

−	create a database definition. How

−	create a user definition. How

2.	(Optional)  Set database capture preferences, if required.  About

3.	Select Generate→Capture Design of→Server Model.

4.	On the Source tab, choose the Database option.

5.	Enter the username, password, connect and owner (optional) string to logon to the Oracle database containing the objects to be captured.

6.	Specify a Target Container for captured server model definitions.

7.	From the Capture Implementation Objects Into drop-down list, select the name of the database and user definition where implementation specific details are to be stored.

Captured implementation details will be associated with the database and user definition you select here.

8.	(Optional) If the source database references database objects which are not being captured but definitions for them exist in the repository, use the Additional Containers field to specify where the referenced object definitions are located.

9. 	Specify your preferred capture options.

10.	(Optional)  To display captured tables, views, materialized views, constraints and clusters in a Server Model Diagram at the end of the capture process, select Show Results on new Server Model Diagram.

11.	Select the Objects tab.

12.	Choose the database objects you want to capture, by moving them to the Capture list box.

13.	Select Start to begin the capture process.

Next step?

During the capture process, errors are written to an error log file and displayed in the message window. You can correct these errors and re-run the Capture Server Model facility as many times as you like.

You can then examine the captured objects in the Navigator or on a Server Model Diagram, modify their definitions and create and delete objects as required.

Note:	Some objects do not have graphical representations. To display and edit objects of any type, use the Navigator.


Capturing objects from another database

Where am I?

A server model can be captured directly from an online ODBC database. Before you begin, you should be familiar with the prerequisites for database design capture. About

At the end of the capture process, the captured objects are displayed in the Navigator. If preferred, captured objects can be viewed graphically on a Server Model Diagram.

To capture a server model from an online ODBC database:

1.	Ensure that a database definition and user definition exist for you to use. Database and user definitions are displayed in the Database Administration view in the Navigator. If not, first:

−	create a database definition. How

−	create a user definition. How

2.	(Optional)  Set database capture preferences, if required.  About

3.	Select Generate→Capture Design of→Server Model.

4.	On the Source tab, choose ODBC.

5.	Select the data source for the database you want to access.

If no data source is available, cancel this dialog and set up a new data source to the database you want to access. How

By default, the database type is automatically displayed in the Type field.

Note:	If no database type is displayed, select the database type that matches the source database. If the database type you want is not listed, select ANSI 92.

6.	Specify a Target Container for captured server model definitions.

7.	From the Capture Implementation Objects Into drop-down list, select the name of the database and user definition where implementation specific details are to be stored.

Captured implementation details will be associated with the database and user definition you select here.

8.	(Optional) If the source database references database objects which are not being captured but definitions for them exist in the repository, use the Additional Containers field to specify where the referenced object definitions are located.

9. 	Specify your preferred capture options.

10.	(Optional)  To display captured tables, views, materialized views, constraints and clusters on a Server Model Diagram, select Show Results on a new Server Model Diagram.

11.	Select the Objects tab.

12.	Choose the database objects you want to capture, by moving them to the Capture list box.

13.	Select Start to begin the capture process.

Next step?

During the capture process, errors are written to an error log file and displayed in the message window. You can correct these errors and re-run the Capture Server Model facility as many times as you like.

You can then examine the captured objects in the Navigator or on a Server Model Diagram, modify their definitions and create and delete objects as required.

Note:	Some objects do not have graphical representations. To display and edit objects of any type, use the Navigator.


Capturing objects from a DDL script

Where am I?

A server model can be captured from a DDL script file. The entire contents of the file are captured.

If multiple files are to be captured they must all reside in the same directory. You will also need to create a master command file that calls each subsidiary file in the correct order.

Before you begin, you should be familiar with the prerequisites for database design capture.  About

To capture a server model from a DDL script file:

1.	Ensure that a database definition and user definition exist for you to use. Database and user definitions are displayed in the Database Administration view in the Navigator. If not, first:

−	create a database definition. How

−	create a user definition. How

2.	(Optional)  Set database capture preferences, if required.  About

3.	Select Generate→Capture Design of→Server Model.

4.	On the Source tab, select the DDL Files option.

5.	Enter the name and location of the file to be captured.

Select previously captured files from the drop-down list, or use the Browse facility. If multiple files are to be captured, specify the name of the master command file.

6.	From the Type drop-down list, select the type of DDL syntax to be captured.

If the type you want is not listed, select ANSI 92.

7.	Specify a Target Container for captured server model definitions.

8.	From the Capture Implementation Objects Into drop-down list, select the name of the database and user definition where implementation specific details are to be stored.

Captured implementation details will be associated with the database and user definition you select here.

9.	(Optional) If the source database references database objects which are not being captured but definitions for them exist in the repository, use the Additional Containers field to specify where the referenced object definitions are located.

10.	(Optional)  To display captured tables, views, materialized views, constraints and clusters on a Server Model Diagram, select Show Results on a new Server Model Diagram.

11.	Specify your preferred capture options.

12.	Select Start to begin the capture process.

Next step?

During the capture process, errors are written to an error log file and displayed in the message window. You can correct these errors and re-run the Capture Server Model facility as many times as you like. Each time you run the utility with the Show results on diagram option selected, a new Server Model Diagram is created.

You can examine the captured objects, modify their definitions and create and delete objects as required.

Note:	Some objects do not have graphical representations on Server Model Diagrams. To display and edit objects of any type, use the Navigator.


Capturing object definitions from multiple DDL scripts

Where am I?

To capture multiple script files, you must create a master file that includes the other files in the correct order.

Note:	All files, including the master command file, must reside in the same directory.

To capture multiple DDL scripts

1.	Create a master command file, if none already exists.

2.	Include in the master command file the name of each file to be captured, by specifying an @ sign followed by the file name. For example:

−	@ <file_name>.<type>

Commands should be included in the following order. For example:

−	cluster

−	table

−	materialized view

−	index

−	constraints

−	views

−	sequences

−	package specification

−	procedure

−	function

−	package body

−	grants

−	synonyms

−	triggers

3.	Capture the master command file.


About reference code tables

Related Topics

A reference code table is a database table containing values, abbreviations and meanings of allowable values defined for columns, their associated domains and unbound items. The reference code table is generated to provide validation for module items that are based on columns, domains or unbound items that have allowable values. This table stores the allowable values defined against column, domain and unbound item definitions in the repository that have the Dynamic List? property set to Yes.

When to use reference code tables

The reference code table provides several advantages over hard-coding allowable values in application code, by:

•	ensuring data integrity - validation criteria is stored centrally on the server

promoting code reuse - values in the reference code table can be referenced by multiple applications of different languages. If the application inserts and updates data via the Server API, validation against the reference code table is performed by Server API procedures.  About

•	reducing maintenance costs - if business rules change, values in the reference code table can be updated independently of the application, without the need to recompile generated applications

The specific uses of the reference code table by different types of generated application are summarized below.

Module type:	Use the reference code table to:
Form	• Provide values for dynamic combo-boxes, poplists and text lists • Populate native Oracle Forms LOVs from a query record group • Validate items
Report	• Validate parameters
Visual Basic/Web PL/SQL	• Provide a dynamic list of values (LOV) • Validate controls
When to generate reference code tables

You should generate all table definitions (including the reference code table) before generating Form, Report, Web PL/SQL Generator and Visual Basic modules that contain bound/unbound items with allowable values.  How

During table generation, the reference code table (CG_REF_CODES by default) and its allowable values are generated to files <File_Prefix>.tab and <File_Prefix>.avt respectively.  When the scripts are run, the allowable values are inserted into the reference code table.

When to  update reference code tables

If allowable values are subsequently added, changed or deleted in the repository, the content of the reference code table must be updated. This ensures validation always take place against the most up-to-date values. How

You can generate a reference code table and allowable values for a particular table or application module, or for sets of tables and modules.  The DDL can be generated to a file <File_Prefix>.sql or directly to the database (cdsddl.sql). When the script is run, the latest allowable values are inserted into the reference code table.

Tip:	If you are maintaining more than one reference code table, generate the latest allowable values to a file and then run the generated script against all previously created reference code tables.

Generation options

•	To generate reference code table at the same time as table definitions or table implementations, choose Options→Generator Options→Database→Automatic Creation of REF_CODES

•	To change the scope and name of reference code tables, choose Options→Generator Options→General→Scope of Reference Code Table

•	To define a tablespace for generated reference code tables, specify Options→Generator Options→General→Tablespace for Reference Code Table

Reference code tables v.’s domain key constraints

The Generate Reference Code Table utility generates allowable value either as the literal value specified, or evaluates the function. If necessary the utility also manipulates the output into a character representation using the default Format Mask defined during generation.

Take care entering functions which perform date or number conversions. For example, if you specify the allowable value TO_DATE('05-06-1999','DD-MM-YYYY') an insert statement is generated to set the character column in the reference code table. As this expression returns a DATE datatype an implicit format mask is used to convert it to a character string. Typically a value of '05-MAY-99' would be stored.

Note:	This may cause problems if an application, running in French for example, tries to check a user entered value against the list of allowable values. In this instance the string would be expected to be in French format, e.g. '05-MAI-99'.  For this reason it is recommended that domain key constraints are used instead of allowable values to define DATE and NUMBERIC sets of values.


Generating reference code tables manually

Related Topics

A reference code table is a database table containing values, abbreviations and meanings of allowable values defined for columns, their associated domains and module unbound items.  About

To generate and populate a reference code table with allowable values associated with one or more modules (or tables):

1.	In Design Editor, choose Options → Use Property Palette.

2.	Select the Modules tab in the Navigator.

3.	Select the required module(s) or relational table definitions.

4.	Ensure that all columns, domains and unbound items with allowable values (to be stored in reference code tables), have the Dynamic List? property set to ‘Yes’.

In this case, data integrity is only ensured if you generate the Table API. For instance, when you specify a domain on a column and set the domain property Dynamic List? to Yes, a reference code table will be used instead of a constraint.

Subsequently, during generation you do not get a warning or a message, and no code is generated to ensure the data integrity for the column with the domain.

5.	Choose Generate→ Generate Reference Code Tables.

6.	Set up the Target and Objects tabs.

Note:	To ensure that validation takes place, the reference code table must be created in the database that will be accessed by the application modules.

7.	To store all generated files in the repository, check the Upload generated output to Repository checkbox. About

8.	Select Start.

The reference code table and any associated allowable values are generated.

By default, a single table called CG_REF_CODES is generated to store the allowable values defined for columns, domains and unbound items in all containers. Alternatively, you can set the Scope Of Reference Code Table option so that a reference code table is generated for a specific container. How


Generating reference code tables automatically with table definitions

Related Topics

A reference code table is a database table containing values, abbreviations and meanings of allowable values defined for columns, their associated domains and module unbound items.  About

To generate and populate a reference code table with allowable values automatically with table definitions:

1.	In Design Editor, choose Options → Use Property Palette.

2.	Select the Server Model tab in the Navigator.

3.	Select the required relational table definition(s).

4.	Ensure that all columns and any associated domains with allowable values (to be stored in reference code tables), have the Dynamic List? property set to ‘Yes’.

Note:	The property must be set for both the columns and associated domains (if there are any) in order for the reference code table to be created and populated automatically.

Data integrity is only ensured if you generate the Table API. For instance, when you specify a domain on a column and set the domain property Dynamic List? to Yes, the reference code table will be used instead of a constraint. Subsequently, during generation you do not get a warning or a message, and no code is generated to ensure the data integrity for the column with the domain.

5.	Select Generate→ Generate Database from Server Model.

6.	Set up the Target and Objects tabs for the required table(s).

7.	Choose Options and select the Automatic Creation of REF_CODES option.

8.	Select OK.

9.	Select Start.

The table(s), the reference code table and any associated allowable values are generated.

By default, a single table called CG_REF_CODES is generated to store the allowable values held against the columns and domains in all containers. Alternatively, you can change the Scope Of Reference Code Table option which generates a reference code table for a specific container. How


Defining database administration objects (step-by-step)

Use the DB Admin tab on the Navigator to define database administration objects for your target database (database definitions, users, schema objects (e.g. table implementations), roles, storage details, etc.). If you define users for your target database, you can also use this tab to define user-specific server model implementations. For example, you can define unique storage characteristics, implementation details and privileges for database objects that are specific to a particular user.  About

Use this flowchart illustrating the process to step through the tasks one at a time. To jump to a task, click on the appropriate step.

Oracle databases

	Define database users  Define database roles Grant/revoke privileges:    - system     - database objects	Create Oracle    Design database objects for a specific user:   - tablespace   - storage details   - data blocks   - privileges   - table partitions	database definition Define database profiles	Define database storage details:   - tablespaces   - rollback segments   - data files/log files   - directories  Allocate tablespace quotas
Other databases

	Create a database definition for other databases           Define database users              Define tablespaces	Design database objects for a specific user:       - tablespace


Enhancing the database design

Designing database administration objects

Creating database definitions

Defining database users

Defining user roles

Defining database profiles

Granting and revoking system privileges

Granting and revoking database object privileges

Defining physical storage requirements

About storage parameters

Defining database storage details

Defining global storage definitions

Defining storage parameters for specific Oracle objects

Defining storage parameters for specific objects in other databases

Tailoring server models for specific database users

About base database objects

About user-specific database objects

Designing objects for a specific database user

Refining the design for improved performance

Creating indexes

Duplicating columns for improved performance

Generating auditing information

About journal tables

Creating journal tables


Creating database definitions

Related Topics

You should create a database definition before capturing an existing database, generating a new physical database and when designing a distributed system. If no database definition exists, you will be prompted to create one.

To define a database definition:

1.	Click the DB Admin tab on the Navigator.

2.	Choose Options→Use Property Dialogs

3.	Select the Databases node (Oracle or other databases) and click

4.	Enter the following information:

•	Unique Name

•	Local Name

•	Version of Oracle database (for Oracle database), or Database type (for other databases)

•	Character Set (for Oracle database only)

Note:	You cannot change the character set after the physical database is created.

For an Oracle database there is the option of selecting the Next button to create database users, tablespace definitions and roles.

5.	Select Finish.

Tip:	You can further define database definitions using additional properties on the Property Palette.

Next step

Create database users. How


Defining database users

Related Topics

You should create a database user definition before capturing an existing database, or before generating a new physical database. If no database user definition exists, you will be prompted to create one.

To define a database user definition:

1.	Click the DB Admin tab on the Navigator.

2.	Choose Options→Use Property Dialogs

3.	Expand the appropriate Databases node (Oracle or other database).

4.	Select the Users node and then click

To get help about a dialog box field click ? and then click on the field.

5.	Enter the following information:

•	User name

•	Password the user must enter to log on to the database

•	(Optional) Tablespace settings (default and temporary)
If no settings are specified, the SYSTEM tablespace is used for both default and temporary tablespaces. When a user executes a SQL statement that will result in a temporary segment being created, it is held in the temporary tablespace.

•	Space usage quotas for tablespaces
This allows the user to create database objects for which they have privileges in a specified tablespace and it also puts a limit on the amount of space that can be occupied by user objects. By default, no quota is allocated. You should give users a quota on a tablespace, or grant permissions to create objects in another user's tablespace.

•	Grant privileges to enable the user to create and or alter objects, as appropriate. You must grant the user the Create Session privilege, to allow the user to log on to the database.

Tip: 	If many users require the same privileges, create a user role and grant privileges to the role. The role can then be associated with all users who require those privileges.

How

•	(optional)  Grant roles to the user as appropriate

6.	Select Finish.

Tip:	You can further define database user definitions using additional properties on the Property Palette.


About user roles

Related Topics

Roles are named groups of related privileges that can be granted to other users and roles. You can create user roles using the DB Admin tab on the Navigator. How

Naming roles

Within a database, each role name must be unique, and no user name and role name can be the same.

Using roles to manage database privileges

Roles allow for easier privilege management within a database. For example,

•	Reduced privilege administration. Rather than granting the same set of privileges explicitly to several users, you can grant the privileges for a group of related users to a role, and then only the role needs to be granted to each member of the group.

•	Dynamic privilege management. If the privileges of a group must change, only the privileges of the role need to be modified. The security domains of all users granted the group's role automatically reflect the changes made to the role.

•	Selective availability of privileges. You can selectively enable or disable the roles granted to a user. This allows specific control of a user's privileges in any given situation.

•	Application-specific security. You can protect role use with a password. Applications can be created specifically to enable a role when supplied the correct password. Users cannot enable the role if they do not know the password.

Who can grant or revoke roles?

Any user with the GRANT ANY ROLE system privilege can grant or revoke any role (except a global role) to or from other users or roles of the database.  Any user granted a role with the ADMIN OPTION can grant or revoke that role to or from other users or roles of the database. This option allows administrative powers for roles on a selective basis. About


Defining user roles

Related Topics

Roles can be defined for databases defined in the repository. Roles are named groups of related privileges that can be granted to other users and roles.

About

To create a user role:

1.	Click the DB Admin tab on the Navigator.

2.	Choose Options→Use Property Dialogs.

3.	Expand the appropriate Databases (Oracle) node.

4.	Select the Roles node and click

To get help about a dialog box field click ? and then click on the field.

5.	Enter the following information:

•	Unique name

•	(optional) Password to protect the role

•	Grant previously defined roles

•	Grant system privileges to the role

6.	Select Finish.

Tip:	You can further define user roles using additional properties on the Property Palette.


About database profiles

Related Topics

A profile is a named set of specified resource limits that can be assigned to a valid user of an Oracle database. You can define profiles to limit the resources available to a user in a single call or session. How

Resource limits must be enabled before they can be used, although you can specify resource limits first.

When to use profiles

You need to create and manage database profiles only if resource limits are a requirement of your database security policy. To use profiles, first categorize the related types of users in a database. Just as roles are used to manage the privileges of related users, profiles are used to manage the resource limits of related users.

Determine how many profiles are needed to encompass all types of users in a database and then determine appropriate resource limits for each profile.

Determining values for resource limits of a profile

Before creating profiles and setting the resource limits associated with them, you should determine appropriate values for each resource limit. You can base these values on the type of operations a typical user performs. For example, if one class of user does not normally perform a high number of logical data block reads, then the Logical Reads Per Session and Logical Reads Per Call limits should be set conservatively.

Usually, the best way to determine the appropriate resource limit values for a given user profile is to gather historical information about each type of resource usage.

For example, the database or security administrator can use the AUDIT SESSION option to gather information about the limits Connect Time, Logical Reads Per Session, and Logical Reads Per Call.

Password settings

When either Password Reuse Time or Password Reuse Max are defined as an integer, the other respectively should be defined as UNLIMITED. If not, an error will be raised (CDS-11020) and the profile won't be generated.


Defining database profiles

Related Topics

You can define profiles for database users defined in the repository. A profile is a named set of specified resource limits and they can be assigned to a specific user. About

To define profiles for database users

1.	Click the DB Admin tab on the Navigator.

2.	Expand the appropriate Databases (Oracle) node.

3.	Define the database profiles:

(a)	Select the Database Profiles node and click

(b)	Enter a unique Name.

(c) 	Set resource limits, as appropriate.

(d)	Click [image] to save.

Note:	When either Password Reuse Time or Password Reuse Max are defined as an integer, the other respectively should be defined as UNLIMITED. If not, an error will be raised (CDS-11020) and the profile will not be generated.

4.	Assign the profile to the database user.

(a)	Choose Options→Use Property Palette

(b)	Double-click the User node.

(c)	From the Database Profile drop-down list, select the profile you have defined.

(d)	Click [image] to save.

Tip:	You can further define database profile privileges using additional properties on the Property Palette.


About granting and revoking database object privileges

Related Topics

System privileges

A system privilege is the right to perform a particular action, or to perform an action on database objects of a particular type. For example, the privileges to create tablespaces and to delete the rows of any table on any user in a database, are system privileges.

You can grant or revoke system privileges to users and roles defined in the repository. How

Who can grant or revoke system privileges?

Only users who have been granted a specific system privilege with the ADMIN OPTION or users with the GRANT ANY PRIVILEGE system privilege (typically database administrators) can grant or revoke system privileges to other users.

Database object privileges

A database object privilege ("object privilege") is a privilege or right to perform a particular action on a specific table, view, sequence, materialized view, procedure, function, package, java class definition, directory or queue implementation. Different object privileges are available for different types of database objects. For example, the privilege to delete rows from the table DEPT is an object privilege.

You can grant or revoke database object privileges for users and roles defined in the repository. How

Some database objects (such as clusters, indexes, triggers, and database links) do not have associated object privileges; their use is controlled with system privileges. For example, to alter a cluster, a user must own the cluster or have the ALTER ANY CLUSTER system privilege.

Who can grant database object privileges?

A user automatically has all object privileges for database objects contained in his or her schema. A user can grant any object privilege on any database object he or she owns to any other user or role. If the grant includes the GRANT OPTION (of the GRANT command), the grantee can further grant the object privilege to other users; otherwise, the grantee can use the privilege but cannot grant it to other users.

Table security

Database object privileges for tables allow table security at the level of DML and DDL operations:

Data Manipulation Language (DML) operations

The DELETE, INSERT, SELECT, and UPDATE privileges allow the DELETE, INSERT, SELECT, and UPDATE DML operations, respectively, on a table or view. You should grant these privileges only to users and roles that need to query or manipulate a table's data. EXECUTE privileges are required to execute functions, procedures and packages and they must be granted directly to the user and not through a role.

You can restrict INSERT and UPDATE privileges for a table to specific columns of the table. With selective INSERT, a privileged user can insert a row with values for the selected columns; all other columns receive NULL or the column's default value. With selective UPDATE, a user can update only specific column values of a row. Selective INSERT and UPDATE privileges are used to restrict a user's access to sensitive data.

For example, if you do not want data entry users to alter the SAL column of the employee table, selective INSERT and/or UPDATE privileges can be granted that exclude the SAL column. (Alternatively, a view that excludes the SAL column could satisfy this need for additional security.)

Data Definition Language (DDL) operations

The ALTER, INDEX, and REFERENCES privileges allow DDL operations to be performed on a table. As these privileges allow other users to alter or create dependencies on a table, you should grant privileges conservatively. A user attempting to perform a DDL operation on a table may need additional system or object privileges (for example, to create a trigger on a table, the user requires both the ALTER TABLE object privilege for the table and the CREATE TRIGGER system privilege).

As with the INSERT and UPDATE privileges, the REFERENCES privilege can be granted on specific columns of a table. The REFERENCES privilege enables the grantee to use the table on which the grant is made as a parent key to any foreign keys that the grantee wishes to create in his or her own tables. This action is controlled with a special privilege because the presence of foreign keys restricts the data manipulation and table alterations that can be done to the parent key.

A column-specific REFERENCES privilege restricts the grantee to using the named columns (which, of course, must include at least one primary or unique key of the parent table).


Granting and revoking system privileges

Related Topics

You can grant or revoke system privileges to users and roles defined in the repository. About

To grant or revoke system privileges

1.	Click the Database Administration tab on the Navigator.

2.	Expand the appropriate Databases (Oracle) node.

3.	Select the user or role definition you require.

4.	Select the Systems Privileges node and click

5.	Do one of the following:

•	To grant a system privilege, move it to the list box on the right

•	To revoke a system privilege, move it to the list box on the left

6.	Click OK.

Tip:	You can further define system privileges using additional properties on the Property Palette.


Granting and revoking database object privileges

Related Topics

You can grant or revoke database object privileges for users and roles defined in the repository. About

To grant or revoke database object privileges

1.	Click the DB Admin tab on the Navigator.

2.	Expand the appropriate Databases (Oracle) node.

3.	Select the user or role definition you require.

4.	Select the Database Object Privileges node and click

5.	Do one of the following:

•	To grant privileges for a database object, move it to the list box on the right

•	To revoke privileges for a database object, move it to the list box on the left

6.	Click OK.

Tip:	You can further define database object privileges using additional properties on the Property Palette.


About storage parameters

Related Topics

You can define different storage parameters for base database objects. This enables you to generate a base database object with different storage parameters for different users. For example, you can generate test and production versions of a base table EMP, that has one set of storage parameters for a test user, and a different set of storage parameters for a production user.

Database objects for which storage parameters can be defined

You can define storage parameters for the following types of database object:

•	tables

•	indexes

•	clusters

•	materialized views

•	materialized view logs

•	rollback segments

•	tablespaces

How storage parameters are defined

Storage parameters can be defined for a specific user's database objects. User-specific database objects are different flavors of the base objects defined in the repository, that are associated with a specific user definition and database. You can define many different implementations of a base object, with different storage characteristics for different users.

About

Before defining storage parameters, a database and user definition must exist for you to use. There are two ways of defining storage parameters, depending on the type of target database on which the objects will be implemented; either:

•	an Oracle database

•	other databases

Storage parameters for Oracle objects

You define storage parameters for Oracle objects by creating storage definitions in the repository. Storage definitions are global objects that you can associate with one or more database objects. How

When you have defined user-specific database objects for the target user and database, you can create storage definitions for those objects, or associate existing storage definitions with the objects. How

Storage parameters for objects for other databases

You define storage parameters for tables and indexes that will be implemented on other databases by entering the STORAGE clause as free-format text against the user-specific database object. How

This is because of the variations in syntax when defining storage on different types of database.


Defining physical storage requirements

Related Topics

You can define specific storage parameters for database objects defined in the repository. About

Defining global storage definitions for Oracle databases

Defining database storage objects

Defining storage parameters for specific Oracle objects

Defining storage parameters for objects for other databases


Defining database storage objects

Related Topics

You can define storage details for databases defined in the repository. For Oracle databases you can define tablespaces, rollback segments, datafiles, logfiles and directories. For other databases, you can define tablespaces only.

To define storage details for Oracle and other databases:

1.	Click the DB Admin tab on the Navigator.

2.	Choose Options→Use Property Dialogs.

3.	Expand the Database node and then the Storage node.

4.	Select the storage element you require and click

•	Tablespaces

•	Rollback Segments

•	Datafiles

•	Logfiles

•	Directories

5.	Enter the information using the dialogs provided.

To get help about a dialog box field click ? and then click on the field.

6.	Click Finish.

Tip:	You can further define storage objects using additional properties on the Property Palette.


Allocating tablespace quotas

You can allocate tablespaces to users on an Oracle database.

To allocate tablespaces to Oracle databases:

1.	Click the DB Admin tab on the Navigator.

2.	Expand the Databases (Oracle) node and then the User node you require.

3.	Select the Tablespace Quota node and click

4.	Move the Tablespace definitions you require to the list on the right.

5.	Click OK.

6.	Define the amount of space allocated to this user:

(a)	Double-click the tablespace quota entry you have just created.

(b)	Set the Quota and Quota Units properties as required.

To get help about a field click ? and then click on the field.

(c)	Click


Defining global storage definitions for Oracle databases

Related Topics

You can define global storage definitions to associate with one or more objects on an Oracle database. About

To create a storage definition for Oracle databases:

1.	Click the DB Admin tab on the Navigator.

2.	Choose Options→Use Property Dialogs.

3.	Select the Storage Definition node and click

To get help about a dialog box field click ? and then click on the field.

4.	Enter the following information:

•	Unique name for the storage definition

•	Extent details

•	Free list details

5.	Click Finish.

Tip:	You can further define storage definitions using additional properties on the Property Palette.


Defining storage parameters for Oracle objects

Related Topics

You can define storage parameters for database objects implemented on a specific Oracle database user. About

To define storage parameters for objects on an Oracle database:

1.	Click the DB Admin tab on the Navigator.

2.	Choose Options→Use Property Dialogs.

3.	Create the Oracle database definition if it does not already exist. How

4.	Define the database user if it does not already exist. How

5.	Select the Schema Objects node and then the implementation node for the type of object for which storage information is to be defined.

For example, Table Implementation, Cluster Implementation, Materialized view Implementation.

6.	Choose Edit→Create

7.	Select the database object for which storage parameters are to be defined and choose Next.

8.	Do one of the following:

−	To create a new storage definition for this database object, select New Storage Definition and define the storage parameters.

−	If the storage definition already exists, select the name of the storage definition that the database object will use from the Storage Definition drop-down list

9.	Click Finish.


Defining storage parameters for objects for other databases

Related Topics	Example

You can define storage parameters for tables and indexes to be implemented on other databases by entering the STORAGE clause as free-format text against a user-specific database object. About

To define storage parameters for objects on other databases:

1.	Click the DB Admin tab on the Navigator.

2.	Choose Options→Use Property Dialogs.

3.	Create the other database definition if it does not already exist. How

4.	Define the database user if it does not already exist. How

5.	Select the Schema Objects node and then the Table implementation node for which storage information is to be defined.

6.	Choose Edit→Create

7.	Select the table for which storage parameters are to be defined.

8.	Click Finish.

9.	Choose Options→Use Property Palette

10.	On the Navigator, double click the table implementation you have created.

11.	Double-click the other database Storage property.

12.	Enter the storage definition in the text area provided

13.	Click [image] to save.


Example - Storage parameters for objects for other databases

Enter the STORAGE clause for tables and indexes to be implemented on other databases against the other databases Storage property of the table implementation.


About base database objects

Related Topics

Base database objects define how information is organized in the database. They include types, tables, views, sequences, materialized views, clusters and PL/SQL definitions. A base object defines the structure of information in the database that is independent of any physical implementation details associated with the target database user. For example, when you create a table, you define its columns, constraints and indexes, without specifying any storage parameters or access privileges for the target user.

After you have created base database objects, you can define different implementations of that object, for multiple different users. You do this by creating user-specific database objects.  About

Base database objects		Properties you can define:	Target database type
Relational Tables		Name Columns, Constraints Indexes, Triggers Synonyms	All supported types
Relational Views		Name, Base tables WHERE clause Constraints, Triggers Synonyms	All supported types
Materialized views		Name, Base tables Constraints Indexes, Synonyms	Oracle
Sequences		Name Synonyms	Oracle
Clusters		Name Cluster columns,  Materialized views, Indexes	Oracle
PL/SQL definitions: • Functions • Procedures • Packages		Name,  PL/SQL body, Package specification, Package body	Oracle
Object Tables		Name Database Triggers Check Constraints Synonyms	Oracle8 database
Object Views		Name Database Triggers  Synonyms	Oracle8 database
Oracle Object Types		Name Attributes, Methods	Oracle8 database
Oracle Collection Types		Name	Oracle8 database
Creating base database objects

You create base objects using the Server Model tab, or Server Model Diagrams.

Generating base database objects

If you select a base database object for generation, all properties stored against the base definition are generated. If a user-specific database object has been defined for a base object, those properties are ignored during generation. About


About user-specific database object implementations

Related Topics

User-specific database object implementations are different flavors of the database object definitions defined in the repository i.e. they are tailored for a specific user. A user-specific database object implementation shares the properties of the database object definition, but has unique storage characteristics, implementation details and privileges that are specific to a particular user. You might think of user-specific database object implementations as corresponding to a user schema on the target database.

When you define user-specific database object implementations, you group collections of database object definitions by user, each with different physical implementation details. How

The relationship between user-specific database object implementations and the database object definitions on which they are defined are illustrated below.

You can define user implementations for the following types of database object definitions. Note that each user can have only one implementation of a database object definition.

Database object definition	User-specific object implementation defines:	Target database type
Relational Tables	Storage parameters,  Tablespace,  Index storage,  Space allocation in data blocks, Privileges	All supported types
Relational Views	Base Relation Location, Privileges	All supported types
Sequences	Sequence values, Privileges	Oracle
Materialized views	Refresh details,  Storage,  Data blocks,  Privileges,  Base Relation Location, Materialized view log	Oracle
Clusters	Storage parameters, Tablespace, Space allocation in data blocks, Index storage	Oracle
PL/SQL Definitions Functions Procedures Packages	Privileges	Oracle
Object Tables	Storage parameters,  Tablespace,  Index storage,  Space allocation in data blocks, Privileges	Oracle8 database
Object Views	Base Relation Location, Privileges	Oracle8 database
Editing user-specific database object implementations

You can display a set of user-specific database object implementations on a Server Model Diagram, if required. Note however, that you cannot create or edit user-specific database object implementations on the diagram.

Impact analysis - Finding out which users use a database object definition

When you define different implementations of a database object definition for multiple different users, you can determine which users have implementation of the database object definition, for impact analysis. Select the database object definition, choose View→ Usages and then Implemented on Schema.

Generating user-specific database object implementations

When you generate user-specific database object implementations, all properties defined for that user and for the database object definition are generated. Select the user-specific database object implementation on the Database Administration tab and then choose Generate→ Generate Database from Server Model.

Note that if you generate the database object definition only, the user-specific properties are not generated.


Designing objects for a specific user

Related Topics

You can tailor a base object defined in the repository for a specific user.

About

To design database objects for a specific user:

1.	If you have not done so already, create the base database object:

(a)	On the Navigator, select the Server Model tab.

(b)	Select the node you require and click

Select one of Relational Table, Object Table, Relational View, Cluster, Sequence, Materialized view, PL/SQL Definition.

2.	If you have not already done so, create a database definition. How

3.	If no user definition exists for you to use, create a user definition with which objects are to be associated. How

(a)	On the Navigator, select the DB Admin tab.

(b)	Choose Options→ Use Property Dialogs

(c)	Expand the Databases and Users nodes to show Schema Objects.

(d)	Select the appropriate implementation object node and click

(e)	Choose the base database object that you want to tailor for this user and then choose Next.

(f)	Enter the following information, as appropriate:

•	Tablespace in which table implementation will be created

•	Storage details

•	Data blocks

•	Privileges for users and roles

•	Table partitions (Oracle8 database)


Duplicating columns for improved performance

In some circumstances, you may want to introduce some controlled redundancy into your table design in order to improve performance. This is sometimes referred to as denormalizing the design. When a table is frequently joined in a query, you can duplicate the referenced column at the foreign key end (many end). The duplicated column removes the need to perform a look-up on a column in another table. Note that denormalization always involves a trade-off between the benefits of increased performance and the overhead of maintaining denormalized columns.

For example, suppose that each time you query employee details, you also want to know the department number to which the employee belongs. Instead of querying the Departments table each time you want to retrieve employee details, you can denormalize the design by duplicating the Department Name column on the Employees table.

To denormalize the design:

1. 	Create an additional column at the foreign key end of joined tables.

2.	Record the denormalization in the repository.

3.	Decide how the denormalized column is to be maintained.

−	To maintain the denormalized column on the server, set the column Server-Derived property to Yes.

−	To maintain the denormalized column on the client, set the Server-Derived property to No (the default).


About journal tables

Related Topics

A journal table is a database table that is used to record details about each row that is inserted, updated or deleted in the associated table. You can specify that a journal table is to be created when you create a table definition. How

The name of the generated journal table is <table_name>_JN. The journal table is a duplicate of the base table but has six additional columns, prefixed with JN_, to maintain transaction information. These columns are described below.

Journal column name	Type of information recorded
JN_OPERATION	Type of transaction performed: INSERT, UPDATE or DELETE.
JN_ORACLEUSER	Name of the Oracle user who performed the transaction.
JN_DATETIME	Date and time the transaction was performed.
JN_APPLN	Name of the application in which the transaction was performed.
JN_NOTES	Notes associated with the transaction.
JN_SESSION	Identifying number of the auditing session for that user.

Journal tables are only generated if the associated table definition has a non-updateable primary key. Therefore, ensure that one exists and that the Complete? property of all primary key columns is set to Yes prior to generation.

Any other column not in the primary key, with the Complete? property set to No is not included in the journal table, but a journal table is still generated.


Creating journal tables

When you design a table, you can optionally generate a journal table to record details about each record that is inserted, updated or deleted in that table. About

When you specify that a journal table is to be created, you must decide how the journal table is to be maintained.

To create a journal table:

1.	On the Navigator, select the Server Model tab.

2.	Choose Options→Use Property Palette

3.	Double click the relational table definition for which a journal table is to be defined.

The table must have a non-updateable primary key so that each row in the table can be identified for update. If one does not exist, you must create one. How

Note: 	Ensure that the Complete? property of all primary key columns are set to Yes.

4.	Set the table Journal property to one of the following.

Client	To maintain the journal table on the client only
Server	To maintain the journal table using Table API triggers. About
Client calls server procedure	To maintain the journal table using procedures that are called directly from the client application.


About distributed database design

A distributed database is a network of databases managed by multiple database servers that appears to a user as a single logical database. The data of all databases in the distributed database can be simultaneously accessed and modified. The primary benefit of a distributed database is that the data of physically separate databases can be logically combined and potentially made accessible to all users on a network.

Each computer that manages a database in the distributed database is called a node. The database to which a user is directly connected is called the local database.

Any additional databases accessed by this user are called remote databases. When a local database accesses a remote database for information, the local database is a client of the remote server (client/server architecture, discussed previously).

While a distributed database allows increased access to a large amount of data across a network, it must also provide the ability to hide the location of the data and the complexity of accessing it across the network. The distributed DBMS must also preserve the advantages of administrating each local database as though it were non-distributed.

Note: 	Information in this section regarding distributed updates and two-phase commit applies only to systems that use Oracle with the distributed option.

Table Replication

Distributed database systems often locally replicate remote tables that are frequently queried by local users. By having copies of heavily accessed data on several nodes, the distributed database does not need to send information across a network repeatedly, thus helping to maximize the performance of the database application.

Data can be replicated using materialized views or replicated master tables. Replicated master tables require the replication option.

Note: The information in this section applies only to Oracle with the distributed or advanced replication options.

Designing distributed objects

Defining public database links

Replicating objects across multiple sites

Creating  master replication groups

Creating replicated groups

Creating materialized view refresh groups


Altering the database design after generation

If changes are made to your server model, you will have to generate DDL for all or part of the model again in order to alter the design on the database.

Reconcile Report

Altering existing objects on a database

Altering database administration objects

Renaming objects on a database

Deleting objects on a database

Altering a table that contains no data

Altering a table that contains data

Deleting columns/attributes from tables containing data

Removing comments

Reconcile Report

If your database is online (Oracle or ODBC), a Reconcile Report (<File_Prefix>.lis ) is generated detailing the objects that need to be created or altered on the database.

After generation you can view the Reconcile Report  to check through the changes that are required, or implement the changes directly on the target database.

The content of the report is controlled via a set of Reconcile Report preferences.

Note:	If you generate DDL to a script file, no cross-referencing/reconciliation can take place.

Altering existing objects on a database

If you try to generate a database object directly on an online database and the object already exists, the DDL necessary to alter the existing object is generated. Note however that comments and repository properties set to null are not reconciled.

Note:	The user must have suitable ‘Alter’ privileges.

Altering database administration objects

DDL cannot be generated to alter database administration object definitions.

Renaming objects on a database

Database objects cannot be renamed during generation.

Deleting objects on a database

Database objects are not dropped from the database automatically.

Oracle8 allows constraints to be dropped via the ALTER TABLE command. Other database versions do not, however you can disable them instead of dropping them. How

Altering a table that contains no data

Prior to Oracle8 only. The restrictions are as follows, you cannot:

•	change a column/attribute from optional to mandatory

•	add a mandatory column/attribute, only optional columns/attributes

•	drop a constraint, but you can disable it

Altering a table that contains data

The restrictions are as follows, you cannot:

•	drop columns/attributes

•	change the column/attribute datatype

•	change the maximum length of columns/attributes

Deleting columns/attributes from tables containing data

Columns/attributes cannot be dropped using the ALTER TABLE command. Create a new table omitting the redundant column and then insert data from the old table into the new one.

Removing comments

Set the Comment property to ' ' (double quote).


Creating master replication groups

A replication group identifies a set of related database object implementations that are to be replicated on one or more databases.

Each replication group is defined for a specific database, known as the ‘master site’. The database objects that comprise the replication group must all be implemented in schemas on the ‘master site’, although not necessarily all in the same schema.

To create a master replication group:

1.	In the Navigator, select the Distribution view.

2.	Expand the Databases (Oracle) node then the database node on which to create the master replication group.

3.	Select the Master Replication Groups node.

4.	Choose Edit→Create.

5.	In the Property Palette, enter the Name.

6.	Click [image].


Creating replicated groups

A replication group identifies a set of related database object implementations that are to be replicated on one or more databases.

Each replication group is defined for a specific database, known as the ‘master site’. The database objects that comprise the replication group must all be implemented in schemas on the ‘master site’, although not necessarily all in the same schema.

To create a replication group:

1.	In the Navigator, select the Distribution view.

2.	Expand the Databases (Oracle) node then the database node on which to create the replicated group.

3.	Select the Replicated Groups node.

4.	Choose Edit→Create.

5.	Move the replication groups you require to the list on the right.

6.	Click OK.

7.	In the Property Palette, set Replication Group properties as required.

Tip:	To get help, click ? and then click the field.

8.	Click


Defining public database links

A public database link is a repository definition that records information about linking a database to another database. Each public database link defines a path to a remote database.

To define a public database link:

1.	In the Navigator, select the Distribution view.

2.	Expand the Databases (Oracle) node then the database node on which to define the public database link.

3.	Select the public database links node.

4.	Choose Edit→Create.

5.	Select one or more database definitions from the list available.

6.	Select OK.

The Property Palette displays the Public Database Link properties.

7.	Click


Defining materialized view refresh groups

A materialized view refresh group identifies a set of materialized view implementations on the same database that are to be refreshed at the same time and at the same time interval. The materialized view implementations that are included in the group do not have to be in the same schema.

To define a materialized view refresh group:

1.	In the Navigator, select the Distribution view.

2.	Choose Options→Use Property Dialogs

3.	Expand the Oracle Databases node, then expand the database node on which to define the materialized view refresh group.

4.	Select the Materialized view Refresh Groups node.

5.	Choose Edit→Create.

6.	Enter a name for the materialized view refresh group.

7.	Choose the materialized views you require.

8.	Click Next to define further properties.

9.	Click Finish.


Generating user-specific database objects

When you generate user-specific database objects, all properties defined for that user and for the base database object are generated. For instance this will generate a table DDL with its storage clause.

Note:	If you generate the base object only, the user-specific properties are not generated.

To generate a user-specific database object:

1.	In the Navigator, select the DB Admin tab.

2.	Expand the Databases, Users and Schema Objects nodes to show the implementation object nodes.

3.	Expand the appropriate implementation object node.

4.	Select the appropriate implementation object definition.

5.	Choose Generate→ Generate Database from Server Model.

6.	Set up the Target and Objects tabs as required.

7.	Select Start.


Oracle parallel server

Accessing the Database as if Connected to Another Instance in a Parallel Server

For optimum performance, each instance of a parallel server uses its own private rollback segments, freelist groups, etc. A database is usually designed for a parallel server so that users connect to a particular instance and access data that is partitioned primarily for their use. If the users for that instance must connect to another instance, the data partitioning can be lost.

The ALTER SESSION SET INSTANCE command allows users to access an instance (specified by setting the integer in the instance property field) as if they were connected to their usual instance.

Note:	The Parallel and Instance table properties are set in the Table Properties palette


Creating DDL grant scripts

You can create and then generate data definition language (DDL) grant scripts for users.

To create a DDL grant script

1. 	create a database user definition.  How

2. 	Create user roles.  How

3. 	Under the role just created, create the database object privileges and system privileges required.

4. 	Assign roles to users.  How

Next step?

Generate the DDL scripts.  How


Granting roles to database users

Related Topics

Database user roles record the roles that are granted to specific database users in the repository.

To assign roles to users

1.	In the DB Admin tab expand the required user node

2.	Select the Roles Granted node.

3.	Choose Edit→Create.

4.	Move the Database User Roles you require to the list on the right.

5.	Click OK.


Entering PL/SQL definitions

Related Topics

About

Approaches to defining PL/SQL definitions

About declarative PL/SQL definitions

About free-format PL/SQL definitions

About text file PL/SQL definitions

PL/SQL functions and procedures

Defining declarative PL/SQL procedures/functions (subprograms)

Defining free-format PL/SQL procedures/functions (subprograms)

Defining text file PL/SQL procedures/functions

Defining Oracle object type methods

PL/SQL packages

Defining declarative PL/SQL packages

Defining free-format PL/SQL packages

Defining text file PL/SQL packages

PL/SQL cursors

Defining PL/SQL cursor definitions

PL/SQL trigger logic

Defining PL/SQL trigger definitions

Undefined PL/SQL logic

Creating undefined PL/SQL definitions

Call specs for publishing Java methods

Defining PL/SQL functions/procedures to publish Java methods

Defining packaged PL/SQL functions/procedures to publish Java methods

Defining Oracle object type methods to publish Java methods

General PL/SQL definition tasks

Defining arguments for PL/SQL definitions

Defining datastructures for PL/SQL definitions

Defining program data constructs for PL/SQL definitions

Granting access privileges to PL/SQL definitions


Approaches to defining PL/SQL definitions

Related Topics

There are three ways you can define PL/SQL code against a PL/SQL definition:

•	In a text file - use this approach to store and maintain PL/SQL code in third-party applications.

•	As free-format PL/SQL - use this approach if you do not intend to reuse the code that is defined in individual definitions. As the code is stored in the repository you can use the Logic Editor syntax checking facility.

•	As declarative PL/SQL - this approach is particularly useful when defining super-definitions, i.e. definitions such as packages that are broken down into sub-definitions. It enables the reuse of code that is defined in individual definitions. As the code is stored in the repository you can use the Logic Editor syntax checking facility.

The approach you choose will depend on:

•	how the PL/SQL code is to be maintained, i.e. in the repository, or in a third-party application.

•	the extent of code to be reused. For example, the declarative approach enables you to define code, such as cursors, once only, so that it is reusable by other definitions.


About text file PL/SQL definitions

Related Topics

PL/SQL definitions can be used to record the name and location of external text files that contain PL/SQL code. How

The entire PL/SQL code, including the CREATE statement, any declarations, executable statements and exceptions, is held in the external source file. Although the code is not stored in the repository, you can use the Logic Editor to build the code from syntactically correct PL/SQL statements. You can import the text file into the Logic Editor and then refine and edit the code as required. You can then export the code back to the external file.  About

By recording the source filename in the repository, you can generate the necessary DDL for the target database.


About free-format PL/SQL definitions

Related Topics

You can define any PL/SQL definition as free-format, however this approach is best suited to procedures, functions and cursors that do not contain nested definitions. ‘Free-format’ indicates the definition is self-contained and has no sub-definitions.

The header generated from a free-format PL/SQL definition includes the CREATE statement, parameters (subprograms and cursors only) and, for functions, the RETURN type.

Free-format subprograms

Use the Navigator to define a free-format subprogram (PL/SQL function or procedure) and then Logic Editor to enter the PL/SQL code for the PL/SQL Block property. How

This example illustrates how a free-format function is defined:

The subprogram header is generated from the PL/SQL definition information and this can optionally include parameters.

The subprogram body is generated from constructs entered via the Private Declaration property and the PL/SQL Block property. You can use the Logic Editor to enter code for the PL/SQL Block, i.e. an executable section and exception handlers.

Private declaration constructs, i.e. declarations of cursors, data structures and program data can be entered separately using the Private Declaration property. If you prefer to use the Logic Editor, private declaration constructs may be entered at the top of the PL/SQL Block instead.

Free-format packages

Use the Navigator to define a free-format package and then Logic Editor to enter the PL/SQL code for the Package Specification and PL/SQL Block properties. A window is displayed for each property in the Logic Editor. The top window defines the Package Specification and the bottom window defines the PL/SQL Block.  How

The content of free-format packages are defined using two different windows in the Logic Editor and the Private Declaration property. The top window defines the Package Specification. The Private Declaration and bottom window defines the Package Body:

The package specification is generated from constructs entered in the Package Specification window (top). The specification contains all public subprogram and cursor declarations.

The package body is generated from constructs entered via the Private Declaration property and the PL/SQL Block property. You can use the Logic Editor to enter code for the PL/SQL Block, i.e. all subprograms and cursors listed in the package specification and any initialization statements (optional).

Private declaration, i.e. any private subprograms, cursors, variables, constants and user-defined datatypes can be entered separately using the Private Declaration property. If you prefer to use the Logic Editor, private declaration may be entered at the top of the PL/SQL Block instead.


About declarative PL/SQL definitions

Related Topics

The declarative approach can be used to define PL/SQL definitions, such as packages, that contain sub-definitions such as subprograms and cursors. You can also use the declarative approach to define subprograms that contain nested subprograms and cursors.

Using this approach, code can be modularized into manageable units that can be reused by other definitions.

Note:	A PL/SQL definition that includes other definitions must be defined as Declarative.

Declarative packages

To model a declarative package, a PL/SQL definition must be defined for the package itself and each sub program unit included in the package. You can then create a PL/SQL composition to describe the content and structure of the package. How

The following illustration shows a PL/SQL composition for a package that includes a function and nested cursor, a free-format procedure and a procedure containing a nested procedure:

The PL/SQL package definition must be defined as ‘Declarative’. However, the PL/SQL definitions within the package (sub-definitions) can be either ‘Free-Format’ or ‘Declarative’.

The scope of each sub-definition must also be specified. Definitions to be made accessible outside the package should have a scope of Public. Public definitions are listed in the package specification. Definitions that are internal to the package should have a scope of Private. Private definitions are omitted from the package specification and are included only in the package body.

The PL/SQL code for each sub-definition can be defined using the Logic Editor. Package initialization statements can also be defined using the Logic Editor. The initialization statements are optional and are generated as part of the package body.

Note:	Private declarations, i.e. any private subprograms or cursors can be entered separately using the Private Declaration property. If you prefer to use the Logic Editor, private declaration may be entered at the top of the PL/SQL Block instead.

The package specification is generated from the PL/SQL package definition and the sub-definitions whose scope is Public. The package body is generated from the PL/SQL code defined in the sub-definitions.

Declarative subprograms

Subprograms can optionally contain other subprograms and cursors. To define a declarative subprogram, a PL/SQL definition must be defined for the subprogram itself and each sub program unit it includes. You can then create a PL/SQL composition to describe the content and structure of the subprogram. How

The PL/SQL subprogram definition (procedure or function) must be defined as ‘Declarative’. However, the PL/SQL definitions included in the subprogram can be either ‘Free-Format’ or ‘Declarative’.  The following illustration shows a PL/SQL composition for a procedure that includes a function, procedure and nested cursor.

The subprogram header is generated from details defined in the declarative PL/SQL definition. This can include the declaration section, comprising parameters, data structures and program data.

The subprogram body is generated from the executable statements and exception handlers associated with the sub-definitions.

Note:	Private declarations, i.e. any private subprograms or cursors can be entered separately using the Private Declaration property. If you prefer to use the Logic Editor, private declaration may be entered at the top of the PL/SQL Block instead.


Defining text file PL/SQL definitions

Related Topics

Instead of storing PL/SQL code in the repository you can import/export code to an external text file. The name and location of the source are specified in the PL/SQL definition. About

To define a text file PL/SQL definition:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Select the type of PL/SQL definition you require and then choose Edit→Create.

4.	Enter a Short name and Name for the PL/SQL definition.

5.	Click Next and specify that the PL/SQL definition is to be an Operating System File.

6.	Click Next and enter the name and location of the file that contains the source code for the PL/SQL definition.

7.	Click Finish.


Defining free-format PL/SQL procedures/functions (subprograms)

Related Topics

You can define any PL/SQL definition as free-format, however this approach is best suited to procedures, functions and cursors that do not contain nested definitions. ‘Free-format’ indicates the definition is self-contained and has no sub-definitions. About

Subprogram is a term that refers collectively to procedures and functions. Procedures and functions have similar structures and are used to perform similar tasks, except that a function returns a value.

To define a free-format procedure or function:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definition node on the Server Model tab.

3.	Select either the Procedure or Function Definitions node and then choose Edit→Create.

4.	Enter a Short name and Name for the PL/SQL definition.

5.	Click Next and specify that the PL/SQL definition is to be Free Format.

6.	If other objects are to access this procedure/function, define the Scope as Public.

7.	For functions only. Choose the Return datatype.

8.	Click Next and define arguments as required.

9.	Click Next twice to display the Advanced page and specify Private Declarations for the procedure/function.

10.	Click Next, choose ‘Create the PL/SQL definition and then invoke the Logic Editor to edit the definition’ and then click Finish.

11.	In the Code Window, define content for the PL/SQL Block property as required and add comments.

Tip:	Choose Utilities→Check Syntax.

12.	Click [image] to save.


Defining declarative PL/SQL procedures/functions (subprograms)

Related Topics

Use the declarative approach to define subprograms that contain nested subprograms and cursors.  About

To define a declarative subprogram and its components:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Define the declarative subprogram:

a	Select either the Procedure or Function Definitions node and then choose Edit→Create

b	Enter a Short name and Name for the PL/SQL definition.

c	Click Next and specify that the PL/SQL definition is to be Declarative.

d	If other objects are to access this procedure/function, define the Scope as Public.

e	For functions only. Choose the Return datatype.

f	Click Next and enter details on the pages that follow to define arguments, exceptions and declarations as required.

g	On the Advanced page, specify Private Declarations for the procedure/function.

h	On the last page choose ‘Create the PL/SQL definition and then invoke the Logic Editor to edit the definition’ and then click Finish.

i	In the Code Window, define content for the PL/SQL Block property as required and add comments.

Tip:	Choose Utilities→Check Syntax

j	Click [image] to save.

4.	Define the sub-definitions to be included within the declarative PL/SQL subprogram.

a	Create a PL/SQL definition for each nested procedure, function or cursor.

Note:	These may be ‘Declarative’ or ‘Free Format’.

b	Add definition logic to each nested procedure, function or cursor.

Tip:	To open the Logic Editor, select the PL/SQL definition on the Navigator and then choose Edit Logic from the right mouse menu.

5.	Define the structure of the declarative PL/SQL subprogram:

a	Expand the PL/SQL Composition node on the Server Model tab.

b	Select the declarative subprogram created in step 3.

c	Choose Sub Program Units from the right mouse menu.

d	Choose the PL/SQL definition(s) you want to include.

Note:	The structure of the declarative subprogram is indicated on the Navigator.

e	To further define the PL/SQL subprogram, select the sub-definition selected in step d and repeat steps c and d.

Note:	The sub-definition you choose must be Declarative.

f	Repeat step e until the structure of your declarative subprogram is complete.


Defining declarative PL/SQL packages

Related Topics

Use the declarative approach to define the program code for a PL/SQL package and its associated sub-definitions.  About

To define a declarative package and its components:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Define the declarative package:

a	Select the Package Definitions node and then choose Edit→Create.

b	Enter a Short name and Name for the PL/SQL package definition.

c	Click Next and specify that the PL/SQL package is to be Declarative.

d	Click Next and enter details on the pages that follow to define exceptions and declarations as required.

e	On the Advanced page, specify Private Declarations for the package.

f	On the last page, choose ‘Create the PL/SQL definition and then invoke the Logic Editor to edit the definition’ and then click Finish.

g	In the Code Window, define content for the PL/SQL Block property and add comments.

Tip:	Choose Utilities→Check Syntax.

h	Click [image] to save.

4.	Define the sub-definitions to be included within the declarative PL/SQL package.

a	Create a PL/SQL definition for each sub-definition to be included in the package.

Note:	These may be ‘Declarative’ or ‘Free Format’.

b	Define the Scope of access property for each sub-definition.

c	Add definition logic for each sub-definition.

Tip:	To open the Logic Editor, select the PL/SQL definition on the Navigator and then choose Edit Logic from the right mouse menu.

5.	Define the structure of the declarative PL/SQL package:

a	Expand the PL/SQL Composition node on the Server Model tab.

b	Select the declarative package created in step 3.

c	Choose Sub Program Units from the right mouse menu.

d	Choose the PL/SQL definition(s) you want to include within the selected package.

Note:	The structure of the declarative package is indicated on the Navigator.

e	To further define the PL/SQL package, select the sub-definition selected in step d and repeat steps c and d.

Note:	The sub-definition you choose must be Declarative.

f	Repeat step e until the structure of your declarative package is complete.


Defining free-format PL/SQL packages

Related Topics

A free-format package is defined using two separate windows in the Logic Editor, one for the package specification and one for the package body.  ‘Free-format’ indicates the definition is self-contained and has no sub-definitions. About

To create a free-format package:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Select the Package Definitions node and then choose Edit→Create.

4.	Enter a Short name and Name for the PL/SQL definition and click Next.

5.	Specify that the PL/SQL definition is to be Free Format and click Next.

6.	Enter the package specification in the text box provided and click Next.

7.	Specify Private Declarations for the package and click Next.

8.	Choose ‘Create the PL/SQL definition and then invoke the Logic Editor to edit the definition’ and click Finish.

9.	In the lower window (package body), define content for the PL/SQL Block property and add comments.

Tip:	Choose Utilities→Check Syntax.

10.	Click [image] to save.


Defining PL/SQL trigger definitions

Related Topics

Use a PL/SQL trigger definition to record trigger logic, i.e. the statements to be executed when a database trigger is fired. About

Note:	A single PL/SQL trigger definition can be used by one or more database triggers.

To define a PL/SQL trigger definition:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Select the Trigger Definitions node and then choose Edit→Create.

4.	Enter a Short name and Name for the PL/SQL definition.

5.	Click Next and specify whether the trigger definition is to be ‘Free-format’, ‘Declarative’ or based on an external  ‘File’.

6. 	Define PL/SQL trigger details on the pages that follow.

The pages and properties displayed depend on your selection in Step 5.

7.	On the Advanced page, specify Private Declarations for the trigger.

8.	On the last page, choose ‘Create the PL/SQL definition and then invoke the Logic Editor to edit the definition’ and then click Finish.

9.	In the Code Window, define the trigger logic required and add comments.

10.	Click [image] to save.

11.	Associate the PL/SQL trigger definition with a database trigger. How


Defining database triggers

Related Topics

A database trigger is defined in two stages. First you define the triggering event, i.e. the INSERT, UPDATE or DELETE statement that causes the trigger to fire against its associated table or view. Then you define the PL/SQL logic that is to be executed when the trigger is fired. About

To define a database trigger:

1.	Choose Options→Use Property Dialogs.

2.	Do one of the following:

•	If the table is displayed on a Server Model Diagram, select the table/view for which the trigger is to be defined.

•	Hold down the right mouse button over the table node, and choose Add Trigger.

Or

•	In the Navigator, select the table/view you require and then the Triggers node.

•	Choose Edit→Create.

3.	Enter a unique name for the trigger.

4.	Select the PL/SQL trigger definition containing the trigger logic.

If the Trigger definition does not yet exist, choose ‘Create default trigger logic’. This creates an empty PL/SQL trigger definition that you can edit  (and add code to) later.

5.	On the pages that follow, specify the trigger event details:

•	the event that will cause the trigger to fire

•	when the trigger will fire

•	the columns for which the trigger is defined

•	any restriction conditions

6.	On the last page, choose the option to open the Logic Editor for the associated PL/SQL definition.

7.	Click Finish.

8.	In the Code Window, view or modify the trigger logic as required.

Tip:	Choose Utilities→Check Syntax.

9.	Click [image] to save.


Defining PL/SQL cursor definitions

Related Topics

You can define a PL/SQL cursor definition that can then be included within a declarative PL/SQL subprogram or package. About

Note:	Cursor statements can also be defined within the declaration section of a free-format subprogram or package, or in an external text file. About

To define a PL/SQL cursor definition:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definition node on the Server Model tab.

3.	Select the Cursor Definitions node and then choose Edit→Create.

4.	Enter a Short name and Name for the PL/SQL definition.

5.	Click Next and specify whether the cursor definition is to be ‘Free-format’, ‘Declarative’ or based on an external  ‘File’.

6. 	Define PL/SQL cursor details on the pages that follow.

The pages and properties displayed depend on your selection in Step 5.

7.	On the last page, choose ‘Create the PL/SQL definition and then invoke the Logic Editor to edit the definition’ and then click Finish.

8.	In the Code Window, define the SQL SELECT statement for the cursor and add comments.

Tip:	You can enter the cursor logic directly into the cursor definition using the PL/SQL Block property, if preferred. Choose Options→ Use Property Palette.

9.	Click [image] to save.

10.	(Optional) Include the PL/SQL cursor definition within other declarative subprograms or packages:

a	Expand the PL/SQL Composition node on the Server Model tab.

b	Select the declarative subprogram or package within which the cursor definition is to be included.

c	Choose Sub Program Units from the right mouse menu.

d	Choose the PL/SQL cursor definition you want to include.

e	To include the cursor definition in other subprograms/packages, repeat steps 10b, 10c and 10d.


Creating undefined PL/SQL definitions

Related Topics

You can define PL/SQL definitions that are not stored as a function, package, procedure, trigger or cursor. About

Note:	Server Generator ignores undefined PL/SQL definitions.

To create an undefined PL/SQL definition:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Select the Undefined PL/SQL definition node and then choose Edit→Create.

4.	Enter a Short name and Name for the PL/SQL definition.

5.	Click Next and specify whether the PL/SQL definition is to be ‘Free-format’, ‘Declarative’ or based on an external  ‘File’.

6. 	Define PL/SQL definition details on the pages that follow.

The pages and properties displayed depend on your selection in Step 5.

7.	On the last page, choose ‘Create the PL/SQL definition and then invoke the Logic Editor to edit the definition’ and then click Finish.

8.	In the Code Window, define the PL/SQL logic required and add comments.

Tip:	Choose Utilities→Check Syntax.

9.	Click [image] to save.

If you want to generate the PL/SQL definition at a later stage, change the Type property from <Null> to Function, Procedure, Package, Trigger Logic or Cursor.


Defining arguments for PL/SQL definitions

Related Topics

Arguments are parameters that are stored against a specific PL/SQL definition. These parameters control which data is used when the PL/SQL definition is run. About

To define arguments for a PL/SQL definition:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Double-click the required PL/SQL definition.

4.	Select the Arguments tab.

Note:	Arguments can not be defined for PL/SQL package definitions, or text file PL/SQL definitions.

5.	In the Arguments field, enter the name of the argument.

6.	From the Defined By dropdown list, select either datatype, domain or datastructure.

7.	Specify datatype, domain or datastructure details as required.

8.	Click Finish to save.


Defining datastructures for PL/SQL definitions

Related Topics

Every constant and variable defined in PL/SQL has a datatype. PL/SQL provides a variety of predefined scalar and composite datatypes (or datastructures). Scalar datatypes, such as VARCHAR2, allow a variable to contain only one value. Datastructures have internal components that can be manipulated individually or as a unit.  About

You can define three types of datastructure: PL/SQL tables, records or cursors. PL/SQL tables and records can each comprise one or more datastructure items that specify the datatypes of the datastructure.

To define a PL/SQL table or PL/SQL record:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Select the Datastructures node of the required PL/SQL definition and then choose Edit→Create.

Note:	Datastructures can be defined for declarative PL/SQL functions, procedures and packages.

4.	Choose the datastructure type.

5.	Enter details on the pages that follow, the properties displayed depend on which datastructure type you have chosen.

6.	Click Finish.

7.	(Optional). Reference the datastructure when defining program data for the PL/SQL definition. How


Defining program data constructs for PL/SQL definitions

Related Topics

You can define program data constructs (variables, constants and user-defined exceptions) for declarative PL/SQL procedures, functions, packages and trigger logic. About

Server Generator uses program data definitions to construct  the DECLARE section in a PL/SQL block.

To define a program data construct:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Double-click the required PL/SQL definition.

Tip:	Declarative PL/SQL definitions only.

4.	Use the Exceptions or Data tabs to define program data constructs.

Note:	For Exceptions, the Oracle Error Code Number field is available only via the Property Palette.

5.	Click Finish.


Granting access privileges to PL/SQL definitions

Related Topics

Individual users or groups of users can be granted or denied access to specific PL/SQL definitions. The extent of a user's access permissions determines whether a user or group of users can connect to a particular database, create objects on the database or grant access permissions to other users. About

To grant or revoke access to a PL/SQL definition:

1.	Choose Options→Use Property Dialogs.

2.	On the DB Admin tab expand the Users node for the required database.

3.	Expand the Schema Objects node.

4.	Select the relevant Implementation node (Function, Package or Procedure) and choose Edit→Create.

5.	Choose the function, package or procedure definition you require from the list.

6.	Click Next to set up access privileges as required.

7.	Click Finish.


About generated database objects

ANSI-compliant objects

About generated relational tables

About generated relational views

About generated constraints

About generated indexes

About generated synonyms

About generated comments

Oracle-specific objects

About generated clusters

About generated PL/SQL definitions

About generated roles

About generated sequences

About generated materialized views

About generated tablespaces

About generated triggers

Oracle8 database objects

About generated Oracle object types

About generated Oracle collection types

About generated object tables

About generated object views

About generated partitioned tables

About generated partitioned indexes

About generated nested tables

About generated index-organized tables

Oracle8.1 database objects

About generated Java objects

About generated function-based indexes

About generated queue tables

About generated persistent queues

About generated non-persistent queues

About generated queue subscribers


About generated relational tables

Target database type:	All
System privileges required:	CREATE TABLE PRIVILEGES (in own schema)
	CREATE ANY TABLE PRIVILEGES (in another user’s schema)
Generated file:	<File_Prefix>.tab
To generate a table, ensure that the table has:

•	a unique name

•	at least one column definition. Varchar2 and Numeric columns must have a maximum length; date columns must have a valid date format and no maximum length. It is recommended that you do not define more than one LONG column in a table.

•	Complete? property of the tables and of all columns to be generated must be set to Yes

Tip:	To prevent a column on a table from being generated, set the Complete? property of the column to No.

•	(recommended) a primary key, that has at least one key column.

Note:	The primary key must be non-updateable (Update?=No) if you intend to generate table handlers for the table (Oracle Designer only).  About

If the target for generation is an online database and the table already exists, the table is altered provided that the table contains no data and the column datatype and length are unchanged.

Other objects generated when you generate a table definition

By default, when you generate a table, the following types of object are also generated, provided they are defined in the repository and are supported on the target database:

•	integrity constraints (primary key, unique key, foreign key, check constraint)

•	indexes

•	triggers (Oracle only)

•	synonyms

•	comments

You can control whether these objects are generated with the table by setting the generation options. How

By default, if you have defined allowable values for a column, valid value constraints are generated to provide validation on the server.

Generated validation and auditing tables (Oracle only)

When you generate a table for an Oracle database, the following types of table definitions may also be generated to provide validation and auditing support for generated applications.

Reference code table	Generated for columns and associated domains with allowable values and whose column property Dynamic List?=Yes
Journal table	Generated if the table property Journal? is set. Note:  A journal table is only generated if the table has a non-updateable primary key. This means that the Complete? property of all primary key columns must be set to Yes.
Generating index-only table information (Oracle8 database)

An index-only table is generated if the table property Index-Only? is set to Yes, and the target database is a Oracle8 database.

Generating storage information for a table

To generate specific storage parameters for a table, you must have defined a table implementation object.  About

Literal values in a partition clause

When generating DDL it should be noted that SYSDATE, USER and NULL expressions are not to be surrounded by quotes (these being the only values that do not require quotes). In the following example using a date column for partitioning, the value-less-than clause reads:

(to_date('01-jan-98'))

Note the quotes surrounding the date string.

create table employee

(empno number(4,0) not null

,ename varchar2(20) null

.. etc.

partition by range (hiredate)

(partition partition_10 values less than (to_date('01-jan-98'))

(partition partition_20 values less than (to_date('01-feb-98'))

If the table were partitioned on ename and hiredate, the value-less-than clause might read:

(‘m’, to_date('01-jan-98'))

for employees with names starting A-L, hired before January 1998.


About generated constraints

By default, constraints defined against a table are generated when you generate the table definition.

Constraint type:	Generated for database type:
Primary key	All
Foreign key	All
Unique key	Oracle, Rdb, DB2, Sybase
Check constraint	Oracle, Rdb, DB2, Sybase
Generated file:	<File_Prefix>.con
All constraints

To generate any of the above types of constraint, ensure that the constraint definition has:

•	a unique name (to ensure against name conflicts when captured constraints are generated to different target databases)

•	at least one key column

•	the Complete? property of the constraint and of the table on which the constraint is defined is set to Yes

•	the option ‘Generate Integrity Constraints’ is selected prior to generation

Tip:	Choose Options→Generator Options→Database and select Generate Integrity Constraints.

This option determines whether all or none of the constraints defined against a table are generated.

Tip:	To control whether or not a specific constraint on a table is generated, set the Complete? property of the constraint to ‘Yes’ or ‘No’ as appropriate.

Foreign keys

In addition, when generating foreign key constraints, ensure that:

•	you have specified whether one or both of the tables involved in the foreign key must be selected for it to be generated  How

•	the number of foreign key columns match the number of referenced primary key or unique key columns

•	the foreign key columns have the same optionality as the referenced primary key or unique key, that is:

−	the foreign key column is mandatory if it references a primary key

−	the foreign key column is optional if it references a unique key

A warning is issued if the optionality of the foreign key constraint if different from the optionality of the key columns. For example, a mandatory foreign key constraint has optional foreign key columns.

•	you have sufficient access permissions on both the source and referenced table

A foreign key cannot be generated if you have access to multiple versions of the reference table. For example, if you have access to multiple versions of a table DEPT that is referenced by a foreign key from EMP.

Note:	You can define constraints against view definitions for use in application design. Note that no DDL is generated for constraints on views.

If the target for generation is an online database and the constraint already exists on the database, the constraint is dropped and then recreated if the key columns defined in the repository have changed. The repository constraint name must be unchanged.

Check constraints

In addition to the conditions required for successful generation of any constraint, ensure that:

•	the check constraint has a PL/SQL statement (body) How

•	a valid check constraint condition is defined

Note: 	Valid value check constraints are generated automatically when you generate a table whose columns or associated domains are defined with allowable values. About


About generated indexes

Target database type:	All, except ANSI 92
System privileges required:	To create an index in your own schema, one of the following conditions must be true: • The table or cluster to be indexed must be in your own schema • You must have INDEX privilege on the table to be indexed • You must have CREATE ANY INDEX system privilege
Generated file:	<File_Prefix>.ind
By default, indexes defined against tables, clusters or materialized views are generated when you generate the table, cluster or materialized view definition.

To generate an index, ensure that the definition has:

•	a unique name

•	at least one indexed column defined

Note:	The datatype of the column cannot be LONG or LONG RAW.

•	the option ‘Generate Indexes’ must be selected prior to generation.

Tip:	Choose Options→Generator Options→Database and select Generate Indexes.

This option determines whether all or none of the indexes defined against the table, cluster or materialized view are generated.

Tip:	To control whether or not a specific index is generated, set the Complete? property of the index to ‘Yes’ or ‘No’ as appropriate.

An index is altered if it exists on the connected database and the index definition or storage parameters have been changed in the repository. The name of the index must be unchanged.

Compute statistics

The CREATE and REBUILD INDEX statements can  include a COMPUTE STATISTICS clause that allows statistics to be gathered incidentally, at minimum cost, during the creation of an index. To generate this clause, set the Compute Statistics? property of the index to Yes.

Generating storage information for an index

To generate specific storage parameters for an index, a user-specific implementation of the database object must first be defined.  About

Function-based index

An index is considered as a function-based index when at least one of its index entries is defined as a function-based index entry.

For generation, the only difference between a function-based and a column-based index is where the index expression is derived from. All other properties of the index remain unchanged and are processed for a function-based index in the same way as for a column-based index.

If the index entry has the property ‘Type’ set to ‘Function based’, the value for the index expression is derived from the property ‘Index function’. Otherwise the value is derived via the assigned column for that index entry.


About generated relational views

Target database type:	All
System privileges required:	CREATE VIEW (in own schema) CREATE ANY VIEW (in another user’s schema)
Generated file:	<File_Prefix>.vw
To generate a view, ensure that the view definition has:

•	a unique name

•	a base relation (if the view is not free-format)

If the view is to be free-format then it requires a valid select clause within the 'Select Text' property.

By default, view statements are generated with the FORCE clause, i.e. CREATE FORCE VIEW. If you only want  views to be created on the database if the base tables exist and the owner of the schema containing the view has privileges on them, set the preference Generate the creation of the Views with Force Clause (GENVFO) to ‘No’.

Altering views

To alter a view, the view is first dropped then recreated using the CREATE VIEW command.


About generated triggers

Target database type:	Oracle only
System privileges required:	CREATE TRIGGER (in own schema) CREATE ANY TRIGGER (in another user’s schema)
Generated file:	<File_Prefix>.tab
A trigger is generated when you generate its associated table. Server Generator generates the commands to create the trigger and also the PL/SQL trigger definition containing the PL/SQL statements to be executed when the trigger is fired. The naming convention used is <table_name>_<trigger_name>.

To generate a trigger, ensure the trigger definition has:

•	a unique name

•	an associated:

−	triggering statement

−	trigger action

−	trigger restriction for Update triggers

•	the Complete? property of the trigger and of the table must be set to Yes

•	the option ‘Generate Triggers’ must be selected prior to generation.

Tip:	Choose Options→Generator Options→Database and select Generate Triggers.

If the target for generation is an online database and a trigger of the same name already exists, the trigger is first dropped then recreated if the update, insert or delete columns or trigger body has been changed in the repository.


About generated synonyms

Target database type:	Oracle
System privileges required:	CREATE SYNONYM (private synonym in own schema) CREATE ANY SYNONYM (private synonym in another user’s schema) CREATE PUBLIC SYNONYM (to create a PUBLIC synonym)
Generated file:	<File_Prefix>.syn
To generate a synonym, ensure that the definition has:

•	a unique name

•	the scope set correctly (Public or Private)

•	Complete? property = Yes


About generated tablespaces

Target database type:	Oracle, DB2
System privileges required:	CREATE TABLESPACE
Tablespaces are created during database administration object generation.

To generate a tablespace, ensure the definition has:

•	a unique name

•	at least one datafile defined

The datafile filename is either derived from the datafile name or the full path name if specified.

Note:	The SYSTEM tablespace will not be generated as this is assumed to be created already (creating the database will create the SYSTEM tablespace). Its existence is purely for documentation and allowing allocation of resource to users, and database-objects assigned to the tablespace.

The auto-extend properties are supported on Oracle 7.3 databases and above.

Database administrator permissions are required:

•	to create or alter tablespaces on the database

•	to execute tablespace definitions against a database

Note:	A tablespace reference is always generated for a database object (table, index) that is associated with a specific tablespace, even if the tablespace definition is not selected for generation.


About generated comments

Target database type:	All
System privileges required:	COMMENT ANY TABLE
By default, comments defined against a database object (table, view, materialized view, column etc.) are automatically generated when you generate the database object definition.

To generate comments, ensure that:

•	a comment is defined against the Comments property of the selected database object definition

Tip:	Do not confuse this property with the Description property, which is used for documentation purposes only. No DDL is generated for Descriptions.

•	the option ‘Generate Comments’ is selected prior to generation

Tip:	Choose Options→Generator Options→Database and select Generate Comments.

•	Complete? property = Yes

Note:	When generating to online databases, comments are not reconciled.


About generated clusters

Target database type	Oracle only
System privileges required:	CREATE CLUSTER (in own schema) CREATE ANY CLUSTER (in another user’s schema) Also, the owner of the schema to contain the cluster must have either space quota on the tablespace containing the cluster or UNLIMITED TABLESPACE system privilege
Generated file:	<File_Prefix>.cls
To generate a cluster, ensure that the definition has:

•	a unique name

•	at least one cluster column

•	Type - either Index or Hash

•	Complete? property = Yes

Note:	The table DDL has to be generated in order to have table columns in the cluster.


About generated PL/SQL definitions

Target database type:	Oracle only
Generated files:	<File_Prefix>.fnc, <File_Prefix>.pks, <File_Prefix>.pkb, <File_Prefix>.prc
PL/SQL definitions are categorized as Functions, Packages, Procedures, Triggers and Cursors (only generated when included as a subprogram for a PL/SQL Package, Procedure or Function).

Each of these have a common set of features that are used in generation:

•	PL/SQL Specification (property of the PL/SQL package definitions)

•	PL/SQL Body (Private Declaration property and PL/SQL Block property)

•	Datastructures (associated with the PL/SQL definition)

•	Program Data (associated with the PL/SQL definition)

•	Subprogram units

Functions

To generate a function, the function must have:

•	a unique name

•	a RETURN type

•	a PL/SQL body statement

You can generate PL/SQL functions that are included within other PL/SQL definitions. However, ‘included functions’ cannot be generated individually, they can only be generated in the context of their owning subprogram or package.

Procedures

To generate a procedure, the procedure must have:

•	a unique name

•	a PL/SQL body statement

You can generate PL/SQL procedures that are included within other PL/SQL definitions. However, ‘included procedures’ cannot be generated individually, they can only be generated in the context of their owning subprogram or package.

Procedures and functions can also use arguments to form part of their declaration.

Packages

When you generate a PL/SQL package, commands are generated to create the package and any PL/SQL functions, procedures or cursors that have been included.

Note:	Included procedures and functions are always generated in the context of the owning package definition and will not be available for selection under the Procedure and Function nodes when you generate the package.

PL/SQL definitions

Procedure definition

Function definition

PL/SQL cursor definition

Procedure definition

Procedures are built up from the following components:

CREATE OR REPLACE PROCEDURE [Short Name or Implementation Name if specified]

( [Argument List]

)

AS

     [Datastructure Definitions]

     [Program Data]

          [Private Declarations held against the Procedure]

          [PL/SQL Cursor Body]

          [SubPrograms]

     BEGIN

          [PL/SQL Block]

     END [Short Name or Implementation Name if specified];

          /

Function definition

Functions are basically the same as procedures but have a Return datatype:

CREATE OR REPLACE FUNCTION [Short Name or Implementation Name if specified]

     ( [Argument List]

     ) RETURN [Return-Type]

     AS

     [Datastructure Definitions]

     [Program Data]

     [Private Declarations held against the Procedure]

          [SubPrograms]

          [PL/SQL Cursor Body]

     BEGIN

     [PL/SQL Block]

     END [Short Name or Implementation Name if specified];

     /

Package Definition

Package are slightly more complex as they are built in two components:

•	Package Specification

•	Package Body

Both these components are generated from a single PL/SQL Definition within the repository.

Package specifications are generated into .pks files. All package specifications are executed before the package bodies.

     CREATE OR REPLACE PACKAGE [Short_Name ]

     AS

          [Datastructure Definitions Having PUBLIC scope]

          [Program Data Having PUBLIC scope]

          [PL/SQL Cursor Specification]

          [SubPrograms Specifications having PUBLIC scope]

          [Package Specification]

               END [Short Name];

          /

Package bodies are generated into .pkb files.

     CREATE OR REPLACE PACKAGE BODY [Short Name ]

     AS

          [Private Declarations]

          [DataStructure Definitions Having PRIVATE scope]

          [Program Data Having PRIVATE scope]

          [SubPrograms Specifications Having PRIVATE scope]

          [SubPrograms Body All]

               [PL/SQL Cursor Body]

          [Definition PL/SQL Body Text after BEGIN Keyword in PL/SQL Block]

               END [Short_Name];

          /

Only the Short Name is used for generation as packages may not be overloaded.

PL/SQL cursor definition

PL/SQL cursors are only generated when included as a subprogram for a PL/SQL package, procedure or function.

When generating for procedures and functions only the cursor body is generated as part of declaration section of the procedure/function. When generating to a PL/SQL package, two possible syntax's can be generated, depending on the scope of the cursor:

•	Public Scope

−	cursor specification is generated to the package specification

−	A cursor body is generated to the package body

•	Private Scope

−	A cursor body is generated to the package body

Cursor Specification

CURSOR cursor_name [(parameter[, parameter]...)] [RETURN return_type] IS select_statement;

where:

•	return_type must represent a record or a row in a database table

•	parameter stands for an argument defined against the PL/SQL definition

Cursor body

The syntax for the cursor specification in the package specification is:

CURSOR cursor_name [(parameter[, parameter]...)] RETURN return_type;

For example a generated package with a PUBLIC cursor will look like:

CREATE PACKAGE emp_actions AS

/* Declare cursor specification. */

CURSOR c1 RETURN emp%ROWTYPE;

     --Note: uses the %ROWTYPE attribute to provide a record type

     -- that represents a row in the database table emp:

END emp_actions;

CREATE PACKAGE BODY emp_actions AS

CURSOR c1 RETURN emp%ROWTYPE IS

SELECT * FROM emp WHERE sal > 3000

END emp_actions;

Subcomponents of PL/SQL generation

Subprograms specification

Used to define the interface for each subprogram unit.

     PROCEDURE [Short Name or Implementation Name if specified]

          ( [Argument List]

          );

     FUNCTION [Short Name or Implementation Name if specified]

          ( [Argument List]

          ) RETURN [Return-Value];

Subprograms body

These are generated in a similar way to stand alone procedures or functions.

Procedures

     PROCEDURE [Short Name or Implementation Name if specified]

     ( [Argument List]

     )

     AS

     [Datastructure Definitions]

     [Program Data]

          [PL/SQL Specification held against the Procedure]

          [PL/SQL Cursor Body]

     [Subprograms]

     BEGIN

     [Definition PL/SQL Body}

     END [Short Name or Implementation Name if specified];

Functions

     FUNCTION [Short Name or Implementation Name if specified]

          ( [Argument List]

          ) RETURN [Return-Value]

     AS

          [Datastructure Definitions]

          [Program Data]

          [PL/SQL Specification held against the Procedure]

          [PL/SQL Cursor Body]

          [Subprograms]

     BEGIN

          [Definition PL/SQL Body}

          END [Short Name or Implementation Name if specified];

Datastructures

Datastructures can be used to define declaratively, a PL/SQL type for a PL/SQL definition.

There are three types of datastructure:

•	PL/SQL record

•	PL/SQL table

•	PL/SQL cursor

The scope of a datastructure is only applicable when defined against a PL/SQL package definition:

•	Public - definition to be made in the package-specification

•	Private - definition only to be made in the package-body

Datastructure items

These are datatypes within a datastructure, e.g. PL/SQL fields within a record. Datastructure Items can either be based on:

•	Datatype, Maximum_length, scale, e.g. Number(3,2)

•	Domain (Datatype, precision, scale picked from domain), e.g. Number(4,0)

•	Table, e.g. emp%ROWTYPE

•	Table and Column, e.g. emp.empno%TYPE

•	PL/SQL definition (package) and PL/SQL definition (Cursor), e.g. MAIN_PACKAGE.CURSOR1

•	PL/SQL definition (package) and program-data, e.g. MAIN_PACKAGE.emp_t%TYPE

•	PL/SQL definition (package) and datastructure, e.g. MAIN_PACKAGE.emp_row

•	Oracle Object Types, e.g. Employee_t

PL/SQL records

TYPE type_name IS RECORD (field_declaration[, field_declaration]...);

PL/SQL tables

TYPE type_name IS TABLE OF element_type [NOT NULL] [INDEX BY BINARY_INTEGER];

PL/SQL cursor

TYPE [Datastructure Name] IS REF CURSOR RETURN [First datastructure item datatype];

Program data

Similar to datastructure items, program data is of the form:

•	Name

•	Type

−	Constant

−	Variable

−	Exception

•	Datatype (not applicable to exceptions)

•	Default Value (not applicable to exceptions)

•	Oracle Error Code Number (only exceptions)

The Datatype is defined by:

•	Datatype, Maximum_length ,scale, e.g. Number(3,2)

•	Domain (Datatype, precision, scale picked from domain), e.g. Number(4,0)

•	Table, e.g. emp%ROWTYPE

•	Table and Column, e.g. emp.empno%TYPE

•	PL/SQL definition (package) and PL/SQL definition (Cursor), e.g. MAIN_PACKAGE.CURSOR1

•	PL/SQL definition (package) and program data, e.g. MAIN_PACKAGE.emp_t%TYPE

•	PL/SQL definition (package) and datastructure, e.g. MAIN_PACKAGE.emp_row

•	Oracle Object Types, e.g. Employee_t

Constants

[Program data Name] CONSTANT [Program data Datatype as above] := [Program data Default_Value];

For example:

credit_limit CONSTANT REAL := 5000.00;

Note:	Constants must always have a default value specified.

Variables

[Program data Name] [Program data Datatype as above] := [Program data Default_Value];

For example:

new_emloyee EMPLOYEE_T := employee_t("Fred Smith");

Exceptions

[Program data Name] EXCEPTION;

For example:

PRAGMA EXCEPTION_INIT([PGD Name], [Oracle Error Code Number]);

Note:	The Pragma clause is only generated if the Oracle error Code Number is specified.

Sub program units

Subprograms can be linked together to form PL/SQL compositions.

Parent PL/SQL definitions can be: PACKAGE, PROCEDURE or FUNCTION

Child PL/SQL definitions can be: PROCEDURE, FUNCTION or CURSOR

PL/SQL definitions that are linked as CALL or null type inclusions are for documentation. Only the CALL type is used to understand dependencies in a PACKAGE definition, which can affect the generation order in the package.


About generated sequences

Target database type:	Oracle
System privileges required:	CREATE SEQUENCE (in own schema) CREATE ANY SEQUENCE (in another user’s schema)
Generated files:	<File_Prefix>.sqs, <File_Prefix>.ccs
Sequences can either be a code-control sequence or an Oracle-sequence. Both types of sequence are selected for generation in the same way.

Code-control sequences

A code control sequence is generated as a table with a domain row that allows for a consecutive sequence number to be created in the application. The statements to create a code control table for code control sequences are generated to the .tab file and the .ccs file.

Oracle sequences

An Oracle sequence generates unique numbers for columns even if rows are created concurrently, but the numbers are not guaranteed to be sequential if a statement is rolled back. An Oracle sequence is generated to a .sqs file.

Sequence implementations

A sequence implementation definition can be used to further define the behavior of a sequence. For example, you can define values for:

•	Start

•	Increment

•	Cache Value

•	Cycle

•	Order

•	Minimum

•	Maximum

Code-control tables only use the Start and Increment-values, whereas an Oracle sequence will use all of the above properties for generation.


About generated materialized views

Target database type:	Oracle
System privileges required:	CREATE MATERIALIZED VIEW, CREATE TABLE and CREATE VIEW, and SELECT privilege on the master tables (in own schema). CREATE ANY MATERIALIZED VIEW and SELECT privilege on the master table (in another user’s schema).
Generated file:	<File_Prefix>.snp
Note:	Materialized view was previously known as snapshot. When a materialized view is generated for an Oracle8.1 database, the MATERIALIZED VIEW clause is generated. When generating for pre Oracle8.1 databases, the SNAPSHOT clause is generated.

To generate a materialized view, ensure that the materialized view has:

•	a unique name

•	the Updateable ? property is set to indicate whether the materialized view is updateable

A materialized view may be defined as either free format or declarative. This determines how the materialized view SQL query will be generated.

Free-format materialized view

Set Free Format Select Text ? = Yes. If using Property Dialogs, select ‘Type in your own materialized view definition’.

The materialized view is generated from these properties held against the materialized view:

•	Select Text

•	Optimizer Hint Clause

•	Where/Validation Condition

Each materialized view definition uses these properties to build the SQL statement in the materialized view definition. If any columns are defined against the materialized view definition then these are generated as column aliases in the create materialized view statement.

Declarative materialized view

Set ‘Free Format Select Text ?’ property = No. If using Property Dialogs, select ‘Choose the tables and columns’.

A declarative materialized view definition allows for greater manipulation of the materialized view without modifying the SQL text manually. It also allows for greater impact analysis as the table usages on the materialized view query are available.

The materialized view is generated from these properties held against the materialized view:

•	Select Text

•	Optimizer Hint Clause

•	Where/Validation Condition

•	Columns

•	Relation Selections

Each materialized view definition uses the Select Text, Optimizer Hint Clause and the Where/Validation Condition to build the SQL statement in the materialized view definition. Columns must be defined to build the ALIAS list and the SELECT list. Relation selections must be defined to build the FROM clause.

Other objects generated when you generate a materialized view definition

By default, when you generate a materialized view, the following types of object are also generated, provided they are defined in the repository and are supported on the target database:

•	integrity constraints (primary key, unique key, foreign key)

•	indexes

•	database synonyms

Materialized view implementations

A materialized view implementation is the intersection between a materialized view and a database user.

Each implementation of a materialized view may specify different storage requirements for the same materialized view. The implementation records:

•	Storage details from the materialized view

•	Refresh details for the materialized view itself

•	Storage details for the materialized view Index

Materialized view implementations can be generated from the DB Admin tab (i.e. in the context of the Database User).  About

Materialized view log generation

A materialized view log, (which is generated to a .snl file) is a table associated with the master table of a materialized view. Oracle stores changes to the master table’s data in the materialized view log and then uses the materialized view log to refresh the master table's materialized views. Therefore materialized view logs are defined against the tables themselves, or rather the table implementation.

Table implementations determine whether a materialized view log is to be created and what storage that materialized view log is to have.

Note:	A materialized view log is not created automatically. It is only generated if the Table Implementation property Materialized View Log ? is set to Yes.

Materialized view restrictions

When generating to Oracle8, materialized views (and materialized view logs) are generated with the WITH ROWID clause (WITH PRIMARY KEY is the database default).

Note:	Oracle7 does not support WITH ROWID or WITH PRIMARY KEY.

Deterministic clause (Oracle8.1)

Functions and procedures need to contain the DETERMINISTIC clause, in order to be referenced and used by materialized views.

If a deterministic function has been defined as a public/private function and included in a package, the DETERMINISTIC clause has to be omitted in the package body.


About generated roles

Target database type:	Oracle
System privileges required:	CREATE ROLE
Generated file:	<File_Prefix>.rle
Database roles are generated during database administration object generation. Roles may consist of roles granted and system privileges.

For example, consider the role PERSONNEL has:

•	SCOTT.EMP granted Select, Insert, Update
SCOTT.DEPT granted Select

The PERSONNEL role is also granted the RESOURCE role that is granted to users:

•	JBLOGGS and JSMITH

In this example, database administration object generation creates DDL:

•	to create the role, PERSONNEL

•	the role RESOURCE will be granted to PERSONNEL

•	the PERSONNEL role will be granted to users JBLOGGS and JSMITH

•	generation, from user SCOTT, will create the tables EMP and DEPT, and also grant privileges on EMP and DEPT to the role PERSONNEL

By default, grants from database objects to roles are not processed during role generation. Instead they are generated when the database objects themselves are generated to the file named File_Prefix.grt. To override this behavior, set the Generate Database Object Privileges with the Roles (GENGRO) preference  to Yes.

Note:	The PUBLIC role corresponds to the public domain in the database. Grants can be made to the PUBLIC role, but the PUBLIC role cannot be created itself or granted from. E.g. you cannot grant PUBLIC to another user or role.


About generated Oracle object types

Target database type:	Oracle8 database
System privileges required:	CREATE TYPE (in own schema) CREATE ANY TYPE (in another user’s schema)
Generated files:	<File_Prefix>.typ <File_Prefix>.tyb   (contain Oracle object type methods)
To generate an Oracle object type, ensure that the type has:

•	a unique name

•	one or more attributes defined

•	(optional) one or more methods

Oracle object type methods

Oracle object type methods are, by definition always ‘public’. Hence the Scope property is ignored during generation.


About generated Oracle collection types

Target database type:	Oracle8 database
System privileges required:	CREATE TYPE (in own schema) CREATE ANY TYPE (in another user’s schema)
Generated file:	<File_Prefix>.typ
To generate an Oracle collection type, ensure that:

•	the Oracle object type on which the nested table or VARRAY is to be based exists

•	the Oracle collection type has a unique name


About generated object tables

Target database type:	Oracle8 database
System privileges required:	CREATE TABLE
Generated file:	<File_Prefix>.tab
To generate an object table, ensure that the table has:

•	a unique name

•	each object table is based on an Oracle object type


About generated object views

Target database type:	Oracle8 database
System privileges required:	CREATE VIEW (in own schema) CREATE ANY VIEW (in another user’s schema)
Generated file:	<File_Prefix>.vw
To generate an object view, ensure that the view has:

•	a unique name

•	the object view is based on an Oracle object type


About generated Java objects

Related Topics

Target database type:	Oracle8.1 database
System privileges required:	To create or replace a Java schema object (source, class or resource) in your own schema, you must have CREATE PROCEDURE system privilege. To create such a schema object in another user’s schema, you must have CREATE ANY PROCEDURE system privilege. To replace such a schema object in another user’s schema, you must also have ALTER ANY PROCEDURE system privilege.
Generated file:	<File_Prefix>.jav
Repository properties:	Java definition properties used during generation
	Java implementation properties used during generation
Note:	To generate valid CREATE JAVA statements, Java implementation details must be defined. How
Consequently, generation must also take place in the context of a Java implementation.

Security

You can define database object privileges for Java source, class and resource definitions. However, no GRANT statements are generated in this release.

Repository properties used during Java object generation

Property	Use during generation	Notes and related topics
Short Name	Not used during database generation.	A name for the Java object definition in the Repository.
Name	Used to name the generated Java object (source, class or resource).  For example, if set to My_Java_Object: • CREATE OR REPLACE JAVA CLASS  USING 'MY_JAVA_OBJECT’ • CREATE OR REPLACE JAVA SOURCE NAMED  "MY_JAVA_OBJECT" • CREATE OR REPLACE JAVA RESOURCE NAMED  "MY_JAVA_OBJECT"	Not used when implementation information defined, i.e. BFILE or LOB column details defined.  (Java source and resource objects only) Not used when an Implementation Name is defined.
Purpose	Not used during database generation.
Type	Class specifies that this Java definition is to load a compiled Java class, in the standard binary format. For example, when set to Class: CREATE OR REPLACE JAVA CLASS Source specifies that this Java definition is to load Java language source text.  For example, when set to Source: CREATE OR REPLACE JAVA SOURCE Resource specifies that this Java definition is to load Java data in standard portable format. For example, when set to Resource: CREATE OR REPLACE JAVA RESOURCE
Implementation Name	Used to name generated Java source or Java resource schema objects.  For Java source objects the implementation name should be the package qualified name of the public class contained in the Java source.  If a call spec is defined for a method in the Java schema object, the name defined here is used to identify the Java      class to which the method belongs.  Note that for Java resource objects this name is just a handle to some other file containing binary data. It won't necessarily contain Java classes. This property is not used when generating from Java class definitions.	If this property is left blank, the Name property (above) is used instead.
Planning	Not used during database generation.
Invocation
Top Level ?	Not used during database generation.
Java
Java Block	Not applicable for Java class or Java resource objects.
	For Java source objects, this property can specify Java language source text. For example: public class Hello {      public static String hello() {        return "Hello World";   } }	Note: Omit the word AS, as this is added automatically during generation. To load existing source code, define a Java source implementation and specify the ‘Create From’ properties. See below.
Documentation
Release Notes	Not used during database generation.
Description	Not used during database generation.
Notes	Not used during database generation.
Repository properties used during Java object implementation generation

Property	Use during generation	Notes and related topics
Complete ?	If set to No, the Java object (source, class, resource) implementation is ignored during generation.
Create From	Specifies how the Java object derives code. The options are • BLOB - code is to be derived from a user-specified BLOB column. Use the BLOB Name property to enter the sub query required to access the code. • CLOB - Java code is to be derived from a user-specified CLOB column. Use the BLOB Name property to enter the sub query required to access the code. • BFILE - Java code is to be derived from a BFILE. This may be either: • an internal BFILE column. In this case, use the BLOB Name property to enter the sub query required to access the code  • an external BFILE on the local file system. In this case, specify the Directory and File Name properties. • <Null> and BLOB Name specifies a key for a LOB column - Java code is to be derived from a column named LOB in table CREATE$JAVA$LOB$TABLE. • <Null> and Java Block specified- Java code is derived directly from source code specified within the Java Block property. Applies to Java source objects only. For example, if set to BLOB: CREATE JAVA CLASS/SOURCE/RESOURCE  USING BLOB   SELECT My_BLOB FROM My_Table WHERE ID=My_Code For example, if set to CLOB: CREATE JAVA CLASS/SOURCE/RESOURCE  USING CLOB   SELECT My_CLOB FROM My_Table WHERE ID=My_Code For example, if set to BFILE: CREATE JAVA CLASS/SOURCE/RESOURCE  USING BFILE   SELECT My_BFILE FROM My_Table WHERE ID=My_Code For example, if set to Null for external .class BFILE: CREATE JAVA CLASS  USING BFILE (bfile_dir, ’Agent.class’); For example, if set to Null and key for LOB column in table CREATE$JAVA$LOB$TABLE : CREATE JAVA CLASS/SOURCE/RESOURCE  USING ‘MyKey’ For example, if set to Null and Java Block specified: CREATE JAVA SOURCE    AS <Java_Block>	If used, the  CREATE$JAVA$LOB$TABLE must have a column LOB of type BLOB and a column NAME of type VARCHAR2.
Database User	Not used during generation.
BLOB Name	If Create From property set to BLOB,CLOB or BFILE: A SELECT statement specifying where the Java code is stored, e.g: SELECT My_CLOB FROM My_Table WHERE ID=My_Code If Create From property set to Null: A key for the column named LOB in table CREATE$JAVA$LOB$TABLE.LOB where the Java code is stored, i.e. a value of the column NAME.  For example, if set to My_Class_Code: CREATE OR REPLACE JAVA CLASS  USING ‘My_Class_Code’	This property is ignored if the Directory and File Name properties define an external BFILE.
Directory	The name of the database directory definition that specifies the file system directory where an external BFILE is stored. First define (and generate) a directory definition, for example My_Dir: CREATE OR REPLACE DIRECTORY MY_DIR AS 'D:\Java_Class' Then, define and generate a Java object that loads a BFILE from My_Dir. For example a Java class object: CREATE OR REPLACE JAVA CLASS  USING BFILE (MY_DIR, '<Class File Name>’)	This property is only used when the Create From property is set to BFILE.
File Name	The name of an external BFILE that contains Java code. For example, a Java class file named My_Code.Class: CREATE OR REPLACE JAVA CLASS  USING BFILE (MY_DIR, 'My_Code.Class')	This property is only used when the Create From property is set to BFILE and the Directory property is defined.
Resolve ?	(Java class and Java source objects only) If set to Yes, an additional RESOLVE statement is generated after the CREATE statement. For example,  CREATE OR REPLACE AND RESOLVE JAVA CLASS CREATE OR REPLACE AND RESOLVE JAVA SOURCE	Not applicable to Java resource objects. If set to Yes, warning CDS-11350 is displayed.
Force ?	(Java class and Java source objects only) If set to No when the Resolve property is set to Yes, an additional NOFORCE statement is generated. For example,  CREATE OR REPLACE AND RESOLVE NOFORCE JAVA CLASS The Force? property is ignored if the Resolve? property is set to No and warning CDS-11350 is displayed.	Not applicable to Java resource objects. If set to Yes, warning CDS-11350 is displayed.
Name Resolution
Resolver Clause	This clause specifies how schemas are searched for referenced fully specified Java names, using the mapping pairs specified when the Java object is created. If specified, the RESOLVER clause is generated.  For example,  RESOLVER (("My_Code.class" USERA) ("My_Package.*" USERB)  (* PUBLIC))	Note: Omit the word RESOLVER from the clause as this is added automatically during generation.
Scope
Global Synonym Name	Not used during database generation.
Scope	Not used during database generation.
Replication
Replication Group	Not used during database generation.
Documentation
Implementation Description	Not used during database generation.
Implementation Notes	Not used during database generation.


About generated function-based indexes

Target database type:	Oracle8.1 database
System privileges required:	To create a function-based index in your own schema, one of the following conditions must be true: • The table or cluster to be indexed must be in your own schema • You must have INDEX privilege on the table to be indexed • You must have CREATE ANY INDEX system privilege
Generated file:	<File_Prefix>.ind
A function-based index is an index on expressions; it enables you to construct queries that evaluate the value returned by an expression, which in turn may include functions (built-in or user-defined).

You can create indexes on functions and expressions that involve one or more columns in the table being indexed. A function-based index pre-computes the value of the function or expression and stores it in the index. You can create a function-based index as either B*-tree or bitmap index.

What determines a function-based index

An index is considered as a function-based index when at least one of its index entries is defined as a function-based index entry.

For generation, the only difference between a function-based and a column-based index is where the index expression is derived from. All other properties of the index remain unchanged and are processed for a function-based index in the same way as for a column-based index.

If the index entry has the property ‘Type’ set to ‘Function based’, the value for the index expression is derived from the property ‘Index function’. Otherwise the value is derived via the assigned column for that index entry.

About the function

The function used for building the index can be an arithmetic expression or an expression that contains a PL/SQL function, package function, C callout or SQL function. The expression cannot contain any aggregate functions, and it must have repeatable values. For building an index on a column containing an object type, the function can be a method of that object, such as a map method.

Note:	You cannot build a function-based index on a LOB column.

Creating function-based indexes on a database

The following statement defines an index on Area (geo):

CREATE INDEX area_index ON rivers (Area(geo)) DESC;

It is also possible to mix columns with the function:

CREATE INDEX idx ON emp (UPPER(emp_name), empno);

Note:	If you are generating a table with function based index, the function that it refers to must exist on the database, i.e. the function must be generated first.

Advantages of function-based indexes

•	support for linguistic sorts based on linguistic sort keys (collation)

•	efficient linguistic collation of SQL statements

•	efficient mechanism for evaluating predicates involving functions

Deterministic clause (Oracle8.1)

Functions and procedures need to contain the DETERMINISTIC clause, in order to be referenced and used by function-based indexes.

If a deterministic function has been defined as a public/private function and included in a package, the DETERMINISTIC clause has to be omitted in the package body.


About generated materialized view logs

The privileges required to create a materialized view log directly relate to the privileges necessary to create the underlying objects associated with a materialized view log.

Target database type:	Oracle
System privileges required:	CREATE TABLE privilege on the master tables (in own schema). CREATE ANY TABLE, COMMENT ANY TABLE and SELECT privilege on the master table (in another user’s schema).
Generated file:	<File_Prefix>.snl
Materialized view log generation

A materialized view log, (which is generated to a .snl file) is a table associated with the master table of a materialized view. Oracle stores changes to the master table’s data in the materialized view log and then uses the materialized view log to refresh the master table's materialized views. Therefore materialized view logs are defined against the tables themselves, or rather the table implementation.

Table implementations determine whether a materialized view log is to be created and what storage that materialized view log is to have.

Note:	A materialized view log is not created automatically. It is created manually in the Table Implementation Properties palette by setting Materialized view Log ? = Yes, and then generating the table implementation.


About generated index-organized tables

Target database type:	Oracle8 database
System privileges required:	CREATE TABLE
Generated file:	<File_Prefix>.tab
To generate an index-organized table, ensure that the table has:

•	a unique name

•	a primary key specified

•	Index-Organized property on the table must be set to Yes

The generated DDL contains the following syntax:

CREATE TABLE...

ORGANIZATION INDEX;


About generated partitioned tables

Target database type:	Oracle8 database
System privileges required:	CREATE TABLE
Generated file:	<File_Prefix>.tab
Literal values in a partition clause

When generating DDL it should be noted that SYSDATE, USER and NULL expressions are not to be surrounded by quotes (these being the only values that do not require quotes). In the following example using a date column for partitioning, the value-less-than clause reads:

(to_date('01-jan-98'))

Note the quotes surrounding the date string.

create table employee

(empno number(4,0) not null

,ename varchar2(20) null

.. etc.

partition by range (hiredate)

(partition partition_10 values less than (to_date('01-jan-98'))

(partition partition_20 values less than (to_date('01-feb-98'))

If the table was partitioned on ename and hiredate, the value-less-than clause might read:

(‘m’, to_date('01-jan-98'))

for employees with names starting A-L, hired before January 1998.


About generated nested tables

Target database type:	Oracle8 database
System privileges required:	CREATE TABLE
Generated file:	<File_Prefix>.tab


About generated partitioned indexes

Target database type:	Oracle8 database
System privileges required:	To create an index in your own schema, one of the following conditions must be true: • The table or cluster to be indexed must be in your own schema • You must have INDEX privilege on the table to be indexed • You must have CREATE ANY INDEX system privilege
Generated file:	<File_Prefix>.ind
Indexes can be local prefixed (unique or nonunique), local nonprefixed (unique, but only when the partitioning key is a subset of the index key or nonunique), or global prefixed (unique or nonunique). Local indexes are always partitioned. Global indexes can be nonpartitioned or partitioned.

Index partitions must be listed in order. For a global index, this means that the partition bound of the first partition listed must be less than the partition bound of the second partition listed, and the partition bound of the second partition listed must be less than the third, and so on. For a local index, you must list the partitions in the same order as the partitions of the underlying table to which they correspond.

Example.

The following statement creates a global prefixed index STOCK_IX on table STOCK_XACTIONS with two partitions, one for each half of the alphabet. The index partition names are system generated:

CREATE INDEX stock_ix ON stock_xactions

(stock_symbol, stock_series)

GLOBAL PARTITION BY RANGE (stock_symbol)

(PARTITION VALUES LESS THAN (’N’) TABLESPACE ts3,

PARTITION VALUES LESS THAN (MAXVALUE) TABLESPACE ts4);


About generated queue tables

Target database type:	Oracle8.1 database
System privileges required:	• EXECUTE rights  to the packages DBMS_AQADM and DBMS_AQ. • MANAGE ANY QUEUE (to create and manage queues in another user’s schema)
Generated file:	<File_Prefix>.aqt
Repository properties:	Queue table properties used during generation
	Queue table implementation properties used during generation
The code generated to create/update queue tables on a database contains calls to the Advanced Queuing API, rather than DDL statements.

Storage information

To generate storage parameters for a queue table, you must define a queue table implementation object.  How

Repository queue table properties used during generation

Property	Use during generation	Notes and related topics
Name	Used to name a generated queue table. The name must not exceed 24 characters as this is the maximum length in Oracle8.1 The name must be unique within all queues, queue tables and queue subscribers in the container.  For example, if set to My_Queue_Table: queue_table => 'MY_QUEUE_TABLE'	If you attempt to generate a queue table with a name greater than 24 characters, the warning CDS-11305 is displayed. The queue table is generated but the name is truncated.
Oracle Type	Identifies the Oracle object type on which the queue table is to be based. (Alternatively, use Scalar Datatype below.) To generate a queue table that uses an Oracle object type to structure and manage message payloads (data), use this property to select the Oracle object type definition you require. Oracle collection types may not be specified. However, Oracle object type attributes based on Oracle collection types are supported providing the Oracle collection type is not a nested table. For example, if set to My_Oracle_Type: queue_payload_type => 'MY_ORACLE_TYPE'	If you attempt to generate a queue table based on an Oracle collection type, the error CDS-11333 is displayed. The queue table is not generated.
Scalar Datatype	Specifies that the queue table is to store message payloads of type RAW, i.e. a queue table with a LOB column is generated. (Alternatively, use Oracle Type above.)  If set: queue_payload_type => 'RAW'	During generation this property is ignored if a value is specified for the Oracle Type property.
Sort List	Identifies the order in which messages will be dequeued from a queue.  For example, if set to ENQ_TIME,PRIORITY: sort_list => 'ENQ_TIME,PRIORITY'
Multiple Consumers?	Specifies whether queues created in the queue table can have a single consumer, or multiple consumers. For example: If set to Yes, the generated queue table stores multiple consumer queues: multiple_consumers => TRUE If set to No, single consumer queues are stored: multiple_consumers => FALSE
Message Grouping	Specifies how messages are grouped in the table. For example: If set to None: message_grouping => DBMS_AQADM.NONE If set to Transactional: message_grouping => DBMS_AQADM.TRANSACTIONAL
Auto Commit ?	If set to No, a COMMIT statement is added after the slash of the PL/SQL block during DDL generation. For example:  If set to Yes: auto_commit => TRUE); END; If set to No: auto_commit => FALSE); END; / COMMIT
Primary Instance	Specifies the instance number of the primary owner of the queue table. For example, if set to 3: primary_instance => 3	You can specify primary instance and secondary instance only in 8.1-compatible mode.
Secondary Instance	Specifies the instance number of the secondary owner of the queue table. For example, if set to 2: secondary_instance => 2	You should not specify a secondary instance unless there is a primary instance.
Compatible Database Version	Specifies the lowest database version compatible with the queue table. For example, if set to 8.1: compatible => '8.1'
Documentation
Comment	A user-specified description for the queue table.  For example, if set to Order Entry Priority comment => 'ORDER ENTRY PRIORITY'
Description	Not used during database generation.
Notes	Not used during database generation.
User Help Text	Not used during database generation.
Repository queue table implementation properties used during generation

Property	Use during generation	Notes and related topics
Queue Table
Name	If you generate queue tables in the context of a database user (i.e. via a queue table implementation), you can choose whether or not the names of generated queue tables are prefixed with the database user name via a preference Use User Qualified Names for Advanced Queuing Objects. For example, if the queue table Name is set to My_Queue_Table, the queue table implementation Database User is set to My_User and the above preference is set to Yes: queue_table => 'MY_USER.MY_QUEUE_TABLE'
Oracle Type	If the queue table is based on an Oracle object type and it is selected for generation via a queue table implementation and the preference is set (as above), the name of the Oracle object type will also be prefixed with the database user name. For example, if Oracle Type is set to My_Oracle_Type and the Database User is My_User: queue_payload_type=>'MY_USER.MY_ORACLE_TYPE
Queue Table Implementation
Complete?	If set to No, the queue table implementation is ignored during generation.	Error message CDS-11312 is displayed.
Database User of Oracle Type	If the queue table is based on an Oracle object type, this property specifies the user definition where the Oracle object type definition is stored. See Oracle Type property above. Note: EXECUTE object privilege required to use an object belonging to another user.	During generation the name of the Oracle object type is prefixed with this User name, if the QULUSR preference is set to Yes.
Storage	This set of properties specify the storage parameter for the queue table. It can be made up of up of any combinations of the following parameters: PCTFREE, PCTUSED, INITRANS, MAXTRANS, TABLEPSACE, LOB and a table storage clause.  Refer to the SQL reference guide for the usage of these parameters. For example: storage_clause => '   PCTUSED 5 PCTFREE 5 STORAGE (INITIAL 500M     NEXT 100M     PCTINCREASE 10     FREELISTS 5     FREELIST GROUPS 5 )  TABLESPACE SYSTEM'
Storage Definition	Added to storage parameter, if defined.
Tablespace	Added to storage parameter, if defined.
Init Trans	Added to storage parameter, if defined.
Max Trans	Added to storage parameter, if defined.
Percent Free	Added to storage parameter, if defined.
Percent Used	Added to storage parameter, if defined.
Documentation
Implementation Description	Not used during database generation.
Implementation Notes	Not used during database generation.


About generated persistent queues

Target database type:	Oracle8.1 database
System privileges required:	• EXECUTE rights  to the packages DBMS_AQADM and DBMS_AQ. • MANAGE ANY QUEUE (to create and manage queues in another user’s schema)
Generated files:	<File_Prefix>.aqp
Repository properties:	Persistent queue properties used during generation
	Persistent queue implementation properties used during generation
The code generated to create/update queues on a database contains calls to the Advanced Queuing API, rather than DDL statements.

Security

To grant (or revoke) privileges to persistent queues you must define a persistent queue implementation. Persistent queue implementation properties override the corresponding definition properties during generation. Also note that in Designer, queue implementation definitions are created in the context of a database, not a user. How

System privileges

You can grant (or revoke) system privileges to (from) a user or a role: ENQUEUE_ANY, DEQUEUE_ANY and MANAGE_ANY.

System privileges for users and roles are generated to the same files as their non-Advanced Queuing counterparts, i.e. <File_Prefix> .usr and <File_Prefix>.rle respectively. How

Queue privileges

You can grant (or revoke) these new queue privileges to (from) a user or a role: ENQUEUE, DEQUEUE, ALL (i.e. ENQUEUE and DEQUEUE). How

Queue privileges (or grants) are generated to the same files as their non-Advanced Queuing counterparts, i.e. <File_Prefix>.grt.

Repository persistent queue properties used during generation

Property	Use during generation	Notes and related topics
Name	Used to name generated queues. The name must not exceed 24 characters as this is the maximum length in Oracle8.1. The name must be unique within all queues, queue tables and queue subscribers.  For example, if set to My_Queue: queue_name => 'MY_QUEUE'	If you attempt to generate a queue with a name greater than 24 characters, the warning CDS-11305 is displayed. The queue is generated but the name is truncated.
Queue Table	Identifies the queue table used to store the queue. For example, if set to My_Queue_Table: queue_table => 'MY_QUEUE_TABLE'	If you attempt to generate a persistent queue that is not assigned to a queue table, error CDS-11024 is displayed. The queue is not generated.
Queue Type	If the Queue Type property is set to Normal: queue_type => DBMS_AQADM.NORMAL_QUEUE If the Queue Type property is set to Exception: queue_type => DBMS_AQADM.EXCEPTION_QUEUE	During exception queue generation, properties Max Retries, Retry Delay, Retention Time and Unlimited Retention Time are ignored. If any of these properties are set, the warning CDS-11336 is displayed.
Auto Commit ?	If set to No, a COMMIT statement is added after the slash of the PL/SQL block during DDL generation. For example: If set to Yes: auto_commit => TRUE); END; If set to No: auto_commit => FALSE); END; / COMMIT
Max Retries	For example, if set to 10 times: max_retries => 10	This property is ignored: • during exception queue generation (Warning CDS-11336) • when the Queue table property Multiple Consumers? is set to Yes and Compatible Database Version is set to 8.0 (Warning CDS-11339)
Retry Delay	For example, if set to 2 seconds: retry_delay => 2	This property is ignored: • during exception queue generation (Warning CDS-11336) • when the Queue table property Multiple Consumers? is set to Yes and Compatible Database Version is set to 8.0 (Warning CDS-11339)
Retention Time	For example, if set to 60 seconds: retention_time => 60 If the Unlimited Retention Time property is set to Yes, this property is ignored and warning CDS-11348 is displayed.	This property is ignored during exception queue generation.
Unlimited Retention Time ?	If set to Yes: retention_time => DBMS_AQADM.INFINITE	This property is ignored during exception queue generation.
Comment	A user-specified description of the queue.  For example, if set to Order Entry Queue comment => 'ORDER ENTRY QUEUE'
Description	Not used during database generation.
Notes	Not used during database generation.
User Help Text	Not used during database generation.
Repository persistent queue implementation properties used during generation

Property	Use during generation	Notes and related topics
Persistent Queue
Name	The name of the generated queue implementation. For example, if Name is set to My_Persistent_Queue queue_name => 'MY_PERSISTENT_QUEUE'	Queues are always created in the same database user as their queue table (see below).
Queue Table	If the Use User Qualified Names for Advanced Queuing Objects preference is set to ‘Yes’, the name of the designated queue table will be prefixed with the queue table database user name. For example, if Queue Table is set to My_Queue_Table and the Database User is My_User: queue_table =>'MY_USER.MY_QUEUE_TABLE	If you attempt to generate a persistent queue implementation that is not assigned to a queue table, error CDS-11024 is displayed. The queue is not generated.
Persistent Queue Implementation
Complete?	If set to No, the queue implementation is ignored during generation.	Error message CDS-11312 is displayed.
Queue Table Database User	Specifies the user definition in which the designated queue table (and this queue) is to be stored.	During generation the name of the queue table is prefixed with the name of this User definition, if the QULUSR preference is set to Yes.
Max Retries	If no value is set here, the value from the persistent queue definition is used during generation. For example, if set to 10 times: max_retries => 10	This property is ignored: • during exception queue generation (Warning CDS-11336) • when the Queue table property Multiple Consumers? is set to Yes and Compatible Database Version is set to 8.0 (Warning CDS-11339)
Retry Delay	If no value is set here, the value from the persistent queue definition is used during generation. For example, if set to 2 seconds: retry_delay => 2	This property is ignored: • during exception queue generation (Warning CDS-11336) • when the Queue table property Multiple Consumers? is set to Yes and Compatible Database Version is set to 8.0 (Warning CDS-11339)
Retention Time	If no value is set here, the value from the persistent queue definition is used during generation. For example, if set to 60 seconds: retention_time => 60 If the Unlimited Retention Time property is set to Yes, this property is ignored and warning CDS-11348 is displayed.	This property is ignored during exception queue generation.
Unlimited Retention Time ?	If no value is set here, the value from the source persistent queue definition is used during generation. If set to Yes: retention_time => DBMS_AQADM.INFINITE	This property is ignored during exception queue generation.
Documentation
Implementation Description	Not used during database generation.
Implementation Notes	Not used during database generation.


About generated non-persistent queues

Target database type:	Oracle8.1 database
System privileges required:	• EXECUTE rights  to the packages DBMS_AQADM and DBMS_AQ. • MANAGE ANY QUEUE (to create and manage queues in another user’s schema)
Generated files:	<File_Prefix>.aqn
Repository properties:	Non-persistent queue properties used during generation
	Non-persistent queue implementation properties used during generation
The code generated to create/update queues on a database contains calls to the Advanced Queuing API, rather than DDL statements.

Non-persistent queues are created on the database with the scalar datatype RAW. They are not based on queue tables as internal tables are used instead.

Security

To grant (or revoke) privileges to non-persistent queues you must define a non-persistent queue implementation. Note that in Designer, queue implementation definitions are created in the context of a database, not a user. How

System privileges

You can grant (or revoke) system privileges to (from) a user or a role: ENQUEUE_ANY, DEQUEUE_ANY and MANAGE_ANY. How

System privileges for users and roles are generated to the same files as their non-Advanced Queuing counterparts, i.e. <File_Prefix> .usr and <File_Prefix>.rle respectively.

Queue privileges

You can grant (or revoke) these new queue privileges to (from) a user or a role: ENQUEUE, DEQUEUE, ALL (i.e. ENQUEUE and DEQUEUE). How

Queue privileges (or grants) are generated to the same files as their non-Advanced Queuing counterparts, i.e. <File_Prefix>.grt.

Repository non persistent queue properties used during generation

Property	Use during generation	Notes and related topics
Name	Used to name generated queues. The name must not exceed 24 characters as this is the maximum length in Oracle8.1. The name must be unique within all queues, queue tables and queue subscribers.  For example, if set to My_NP_Queue: queue_name => 'MY_NP_QUEUE'	If you attempt to generate a queue with a name greater than 24 characters, the warning CDS-11305 is displayed. The queue is generated but the name is truncated.
Multiple Consumers?	Specifies whether the queue allows a single consumer per message, or multiple consumers. For example: If set to Yes, the queue messages may have multiple consumers: multiple_consumers => TRUE If set to No, only one consumer per message is allowed: multiple_consumers => FALSE	On the database, non persistent queues are created in a system created queue table, i.e. AQ$_MEM_SC for single-consumer queues and AQ$_MEM_MC for multi-consumer queues.
Comment	A user-specified description of the queue.  For example, if set to Order Entry Queue comment => 'ORDER ENTRY QUEUE'
Repository non-persistent queue implementation properties used during generation

Property	Use during generation	Notes and related topics
Complete?	If set to No, the queue implementation is ignored during generation.	Error message CDS-11312 is displayed.
Documentation
Implementation Description	Not used during database generation.
Implementation Notes	Not used during database generation.


About generated queue subscribers

Target database type:	Oracle8.1 database
System privileges required:	• EXECUTE rights  to the packages DBMS_AQADM and DBMS_AQ. • MANAGE ANY QUEUE (to create and manage queues in another user’s  schema)
Generated file:	<File_Prefix>.aqs
Repository properties:	Queue subscriber properties used during generation
The code generated to create/update queue subscribers on a database contains calls to the Advanced Queuing API, rather than DDL statements. Also, note that subscribers cannot be generated independently, they are always generated with their respective queue implementation.

Note:	No subscribers are generated for exception queues, or single consumer queues. If subscribers are defined, warnings CDS-11341 (for exception queues) and CDS-11342/CDS-11343 (for single consumer queues) are displayed during generation.

Repository queue subscriber properties used during generation

Property	Use during generation	Notes and related topics
Name	Used to name generated subscribers. The name must be unique within all queues, queue tables and queue subscribers.
Address	Specifies an address for the subscriber. This can be: • a protocol specific address • or, for local subscribers the literal string: null
Protocol	Not used during database generation.	Not currently used in the database. If set, this property is ignored and warning CDS-11340 is displayed during generation.
	For example, if Name is set to MY_SUBSCRIBER, Protocol is left Null and Address is set to My_User.My_Queue@My_Database: subscriber  := sys.aq$_agent ('MY_SUBSCRIBER', 'MY_USER.MY_QUEUE@MY_DATABASE', null)
	For example, if Name is set to MY_LOCAL_SUBSCRIBER, Address has the string value null and Protocol is left empty: subscriber  := sys.aq$_agent ('MY_SUBSCRIBER', null, null)
Rule	For example, if the rule is set to priority < 2: rule => 'priority < 2' If the message payload is based on an Oracle object type the rule may contain references to Oracle object type attributes. If used, each attribute must be prefixed with tab.user_data as a qualifier. For example: rule => 'tab.user_data.orderregion =  ''EASTERN'' OR                               (tab.user_data.ordertype = ''RUSH'' AND                                tab.user_data.customer.country = ''USA'') '	Single quotes are added automatically during generation. This property is not applicable for subscribers of non-persistent queues. If defined, warning CDS-11343 is displayed during generation.
Documentation
Description	Not used during database generation.
Notes	Not used during database generation.
User/Help Text	Not used during database generation.


About captured database objects

ANSI-compliant objects

About captured relational tables

About captured relational views

About captured constraints

About captured indexes

About captured synonyms

About captured domains

Oracle-specific objects

About captured clusters

About captured PL/SQL packages, procedures, functions

About captured roles

About captured sequences

About captured materialized views

About captured tablespaces

About captured triggers

About captured grants

About captured users

Oracle8 database objects

About captured Oracle object types

About captured methods (for Oracle object types)

About captured Oracle collection types

About captured object tables

About captured object views

About captured partitioned tables

About captured partitioned indexes

About captured index-organized tables

About captured nested tables

Oracle8.1 database objects

About captured function-based indexes

About captured Java objects

About captured queue tables

About captured persistent queues

About captured non-persistent queues

About captured queue subscribers

Constructs that cannot be captured


About captured relational tables

Related Topics

Source database type:	All supported types
System privileges:	Access to the table
Capture from database:	Yes
Capture from file:	Yes
Related preferences

Capture table preferences

Capture comments preference (RECCOM)

Capture generated Table API triggers with tables(DTAPIT)

Literal values in a partition clause

When capturing DDL it should be noted that SYSDATE, USER and NULL expressions are not to be surrounded by quotes (these being the only values that do not require quotes).

Note the use of quotes in the following example. Using a date column for partitioning, the value-less-than clause reads (to_date('01-jan-98'))

create table employee

(empno number(4,0) not null

,ename varchar2(20) null

.. etc.

partition by range (hiredate)

(partition partition_10 values less than (to_date('01-jan-98'))

(partition partition_20 values less than (to_date('01-feb-98'))

If the table was partitioned on ename and hiredate the value-less-than clause might read:

(‘m’, to_date('01-jan-98'))

for employees with names starting A-L, hired before January 1998.


About captured constraints

Source database type:	All supported types
System privileges:	Access to the constraint
Capture from database:	Yes
Capture from file:	Yes
Constraint properties	Captured as:
Primary key	Primary key constraint definition on the table.
Unique key	Unique key constraint definition on the table.
Foreign key	Foreign key constraint definition. The source and referenced tables must be selected. The referenced column must always be specified. If it is not, the referenced column is assumed to be the same as the source column and a recursive foreign key is created.
Check constraint	Check constraint definition.  Valid value check constraints (generated to enforce allowable values) are not captured. About
Constraint constructs which cannot be captured

•	Storage parameters cannot be captured for constraints.

•	Exceptions tables cannot be captured for constraints.

•	Enable and Disable clauses are ignored when capturing constraints from files.

Related preferences

Capture table preferences

Capture materialized view preferences


About captured indexes

Source database type:	All supported types
System privileges:	Access to the index
Capture from database:	Yes
Capture from file:	Yes
Related preferences - table indexes

Capture New Table Indexes (ADNINT)

Update Indexes existing in the Repository (INARIT)

Delete Indexes not in the Database (DEINFT)

Related preferences - materialized view indexes

Capture New Materialized View Indexes (ADNINM)

Update Indexes existing in the Repository (INARIM)

Delete Indexes not in the Database (DEINFM)


About captured relational views

Source database type:	All supported types
System privileges:	Access to the view
Capture from database:	Yes
Capture from file:	Yes
During design capture, relational views are captured either as 'free format' or 'declarative' view definitions.

If possible, declarative view definitions are captured, i.e. the Free Format ? property is set to 'No', and it is modeled using Base Table and View Column definitions which point to the tables and columns that the view selects. The Select Text property is left <null> and the content of view’s WHERE clause (if any) is copied to the Where/Validation Condition property.

During the capture process, table and column information is extracted from the view's SELECT and FROM clauses. If any one of the following are detected, a declarative view definition is not captured:

Declarative view not captured if...	Message displayed
A table or column referenced within the view is not modeled in the Repository	CDS-15014 Warning: Invalid Relation reference ('<name>') in View <name>
The SELECT text contains any type of expression (rather than a list of table columns). E.g.	CDS-15326 Warning: Unable to set base column <name> for view column <tab>.<col>
The SELECT text contains comments, an optimiser hint clause or an order by clause	CDS-15353 Warning: View or Snapshot <name> has select text containing <comments/optimiser hints/order by> clause
The number of view columns to be captured does not match the number of base columns present in the view	CDS-15327 Warning: There is a mismatch in the number of view columns and base columns for view <name>
The view references a table or view using a synonym	CDS-15352 Warning: The <view> <name> references a base relation using <synonym> <name>
(Capture from file only) The view is specified using * or tab.* query	CDS-15327 Warning: There is a mismatch in the number of view columns and base columns for view <name>
If a declarative view definition is not captured, a free format view definition is captured instead and message CDS-15325 is displayed, i.e. Warning: Unable to capture View <name> in declarative mode. Reverting to free format.

When a free format view definition is captured, it’s Free Format? property is set to 'Yes', the view's SELECT text is copied to the Select Text property, and the view’s WHERE clause (if any) is copied to the Where/Validation Condition property.

Example 1 - Declarative view definitions

This view will be captured as a declarative view definition:

    create table employees (id number,

                            fullname varchar2(100),

                            department number,

                            monthlysalary number)

    /

    create table departments (id number,

                              name varchar2(20))

    /

    create or replace view empdept(fullname, name) as

       select fullname, name

       from employees, departments

       where employees.department = departments.id

    /

Properties of the captured view, base table and base column definitions are set as follows:

View definition
Free Format Select Text?	No
Select Text	<null>
Where/Validation Condition	employees.department = departments.id
Base table definitions
Table Name (employees)	EMPLOYEES
Table Name (departments)	DEPARTMENTS
View column definitions
Name (fullname)	EMPLOYEES.FULLNAME
Name (name)	DEPARTMENTS.NAME
Example 2 - Free Format view definitions

This view will be captured as a free format view definition as the SELECT text contains an expression 'monthlysalary * 12' that cannot be modeled as a select of a column value.

create table employees (id number,

                            fullname varchar2(100),

                            department number,

                            monthlysalary number)

    /

    create table departments (id number,

                              name varchar2(20))

    /

    create or replace view empannualsalary(fullname, annualsalary) as

       select fullname, monthlysalary * 12 as annualsalary

       from employees

       where monthlysalary > 0

    /

Properties of the captured view, base table and base column definitions are set as follows:

View definition
Free Format Select Text?	Yes
Select Text	fullname, monthlysalary * 12 as annualsalary from employees
Where/Validation Condition	monthlysalary > 0
Base table definitions
Table Name (employees)	EMPLOYEES
View column definitions
Name (fullname)	EMPLOYEES.FULLNAME
Name (name)	<null>
In addition, the following messages are displayed:

CDS-15326 Warning: Unable to set base column monthlysalary * 12 as annualsalary for view column EMPANNUALSALARY.ANNUALSALARY

CDS-15325 Warning: Unable to capture View EMPANNUALSALARY in declarative mode. Reverting to free format

View partitions

Partitions defined within views are not captured.

Related preferences

Capture view preferences

Capture comments preference (RECCOM)


About captured synonyms

Source database type:	Oracle only
System privileges:	Access to the synonym
Capture from database:	Yes
Capture from file:	Yes
Synonyms on synonyms cannot be captured.

Related preferences

Capture synonyms preference (RECSYN)


About captured domains

Source database type:	All supported types
System privileges:	Access to the domain
Capture from database:	Yes
Capture from file:	Yes
	(only for Oracle Lite, DB2 and RDB)


About captured clusters

Source database type:	Oracle only
System privileges:	Access to the cluster
Capture from database:	Yes
Capture from file:	Yes


About captured sequences

Source database type:	Oracle only
System privileges:	Access to the Sequence
Capture from database:	Yes
Capture from file:	Yes
Capturing Start values for sequences

‘Start’ is a Sequence Implementation property and it represents the value at which a new, generated sequence begins counting.

During database capture a value for 'Start' is derived from the sequence as follows: Last_Number + Increment_By. Hence when a sequence is captured, the repository ‘Start’ value is higher than the sequence’s last number.

For example, if you capture a database sequence where Last_Number is 34 and Increment_By is 2, the repository Start value captured is 36.


About captured materialized views

Source database type:	Oracle only
System privileges:	Access to the Materialized view
Capture from database:	Yes
Capture from file:	Yes (except for Oracle Lite)
When a materialized view is created, a table is created to hold relevant information (SNAP$_%) with a primary key being generated for the SNAP$_% table by the server. When capturing the materialized view, the primary key is captured and when the materialized view is re-created, the DDL for that constraint is created. However, Server Generator does not distinguish between a ‘server’ and ‘user’ created primary key, so it tries to create the primary key again.

Partitions

Partitions defined within materialized views are not captured.

Related preferences

Capture materialized view preferences

Capture comments preference (RECCOM)


About captured triggers

Source database type:	Oracle only
System privileges:	Access to the trigger
Capture from database:	Yes
Capture from file:	Yes
If you try to capture a trigger for a table, but the table does not exist in the repository and it is not present as part of the DDL being captured, the trigger statement is ignored. If the table exists in the repository, the trigger is captured and associated with the table.

Related preferences

Capture PL/SQL definition preferences

Capture generated Table API triggers with tables(DTAPIT)


About captured PL/SQL packages, procedures, functions

Source database type:	Oracle only
System privileges:	Access to the PL/SQL package, procedure, function
Capture from database:	Yes
Capture from file:	Yes
Reconciling PL/SQL definitions

Reconciliation is the process of comparing data definitions in the repository with data definitions of the same name that have just been captured. If a PL/SQL definition exists in the repository with the same name as the PL/SQL definition to be captured, the PL/SQL definitions are reconciled with the following results:

•	Captured definitions are displayed in blue, until they are saved

•	If the captured subprogram has new parameters, they are added to the existing subprogram

•	If the captured package contains new definitions, such as procedures, they are added to the existing package

•	Existing PL/SQL logic is not overwritten by captured PL/SQL logic

•	Existing PL/SQL definition properties are not overwritten by captured PL/SQL definition properties

The information in the repository is considered to be reference information. So, only primary elements, such as procedures, and secondary elements, such as arguments, are added. Properties of existing PL/SQL definitions are never overwritten.

Capturing external  procedures

External routines specified using the AS EXTERNAL clause can not be captured. Note however, that in Oracle8.1 this clause has been deprecated and is supported for backward compatibility only. Oracle Corporation recommends that you use the AS LANGUAGE C syntax instead.

Related preferences

Capture PL/SQL definition preferences

Capture generated Table API triggers with tables(DTAPIT)


About captured tablespaces

Source database type:	Oracle; DB2 (name only)
System privileges:	Access to the tablespace
Capture from database:	Yes
Capture from file:	Yes
Note that the Rename Datafile facility is not supported when capturing tablespaces from files.


About captured roles

Source database type:	Oracle only
System privileges:	Access to the role
Capture from database:	Yes
Capture from file:	Yes


About captured grants

Source database type:	Oracle only
System privileges:	Access to the grant
Capture from database:	Yes
Capture from file:	No
Related preferences

Capture grants preference (RECGRT)


About captured users

Source database type:	Oracle only
System privileges:	Access to the User
Capture from database:	Yes
Capture from file:	Yes
Related preferences

Use User Qualified Names for Advanced Queuing Objects (QULUSR)


About captured Oracle object types

Source database type:	Oracle8 database
System privileges:	Access to the Oracle object type
Capture from database:	Yes
Capture from file:	Yes
Attribute sequence number support

Databases earlier than Oracle8.1

When capturing, the order that the attributes and associations to other types appear in the repository does not reflect the order that is shown in the table on the database. Upon generating an Object Type to the database and then capturing it back into another application system, the order of things within the object will then be different. Generating these objects out again does not allow mapping of one object onto the other because their structures are not consistent.

Oracle8.1 database

Server Generator supports type attribute sequence numbers In Oracle8.1 databases. The order that the attributes and associations to other types appear in the repository does reflect the order that is shown in the table on the database. An attribute number column for attributes has been added to the database, ensuring that the required attribute sequence numbers are captured and applied to the appropriate attribute.

Related preferences

Oracle Object Type preferences


About captured Oracle collection types

Source database type:	Oracle8 database
System privileges:	Access to the Oracle Collection Type
Capture from database:	Yes
Capture from file:	Yes


About captured object tables

Source database type:	Oracle8 database
System privileges:	Access to the object table
Capture from database:	Yes
Capture from file:	Yes
Related preferences

Capture table preferences


About captured object views

Source database type:	Oracle8 database
System privileges:	Access to the object view
Capture from database:	Yes
Capture from file:	Yes
Related preferences

Capture view preferences


About captured methods (for Oracle object types)

Source database type:	Oracle8 database
System privileges:	Access to the method
Capture from database:	Yes
Capture from file:	Yes

Oracle object type methods are, by definition always ‘public’. Hence the Scope property is not set during design capture.

The SELF IN OUT parameter type is not supported in this release.


About captured partitioned tables

Source database type:	Oracle8 database
System privileges:	Access to the partitioned table
Capture from database:	Yes
Capture from file:	Yes
Literal values in a partition clause

When capturing DDL it should be noted that SYSDATE, USER and NULL expressions are not to be surrounded by quotes (these being the only values that do not require quotes).

Note the use of quotes in the following example. Using a date column for partitioning, the value-less-than clause reads (to_date('01-jan-98'))

create table employee

(empno number(4,0) not null

,ename varchar2(20) null

.. etc.

partition by range (hiredate)

(partition partition_10 values less than (to_date('01-jan-98'))

(partition partition_20 values less than (to_date('01-feb-98'))

If the table was partitioned on ename and hiredate the value-less-than clause might read:

(‘m’, to_date('01-jan-98'))

for employees with names starting A-L, hired before January 1998.


About captured partitioned indexes

Source database type:	Oracle8 database
System privileges:	Access to the partitioned index
Capture from database:	Yes
Capture from file:	Yes


About captured index-organized tables

Source database type:	Oracle8 database
System privileges:	Access to the index-organized table
Capture from database:	Yes
Capture from file:	Yes


About captured nested tables

Source database type:	Oracle8 database
System privileges:	Access to the nested table
Capture from database:	Yes
Capture from file:	Yes


About captured function-based indexes

Source database type:	Oracle8.1 database
System privileges:	Access to the index
Capture from database:	Yes
Capture from file:	Yes
Capture from file

File capture considers all index expressions which are not column names of the table as function-based.

Note:	Careful design is required when comparing column names in a file with column names in the repository (due to quotes, capitals, etc.).


About captured Java objects

Source database type:	Oracle8.1 database
System privileges:	Access to the Java object
Capture from database:	Yes (Java source only)
Capture from file:	Yes
Repository properties:	Java definition properties set during design capture from file
	Java implementation properties set during design capture from file
	Java source properties set during design capture from database
	Java source implementation properties set during design capture from database
During design capture, new Java class, source and resource definitions and their associated Java implementations are created in the repository and in most cases properties of existing Java definitions are simply updated. However, definitions for Java classes which use sub queries to derive code from BLOB/CLOB/BFILE columns are never updated during capture. Instead, new Java class definitions are always created.

Note:	Only Java source objects can be captured from databases.

Repository Java definition properties set during design capture from file

Property	Set during capture	Notes and related topics
Short Name	Value captured for Java source/class/resource.	If necessary, the Short Name is truncated to 20 characters.
• Java source / resources	For Java source and resource definitions, the Short Name property is derived from the NAMED clause.	For example, when capturing CREATE JAVA SOURCE NAMED "Hello".. the Short Name property is set to HELLO
• Java classes	Java class objects do not contain the NAMED clause. The Short Name property is derived in one of the following ways: Java class Name property External BFILE Name of the .class file	For example, when capturing CREATE JAVA CLASS USING BFILE (bfile_dir, ’Agent.class’) the Short Name property is set to AGENT
	Subquery for LOB column JA_<LOB Type><n>	For example, when capturing:  CREATE JAVA CLASS  USING BLOB SELECT ... the Short Name property is set to JA_BLOB
	Key for LOB column Key name	For example, when capturing:  CREATE JAVA CLASS  USING ‘MyKey’ the Short Name property is set to MYKEY
Name	The Name is set to the Short Name by default.
Purpose	No value captured.
Type	Set to one of Class, Source or Resource depending on the type of Java object being captured, i.e. Java class, source or resource respectively.
Implementation Name	Value captured from Java source and resource objects only.  The value is derived from the NAMED clause, except when capturing Java source objects containing the AS clause. In this particular case, the full name of the first class (or interface) defined within the Java source code is used, i.e. [package_name.]<class_or_interface_name>	Not applicable for Java classes.
Planning	No values captured.	Default values used.
Invocation	No values captured.	Default values used.
Java
Java Block	Java source text is only captured from Java source objects that contain the AS clause.	Not applicable for Java class or resource objects.
Documentation
Release Notes	No value captured.
Description	No value captured.
Notes	No value captured.
Repository Java implementation properties set during capture from file

Property	Set during capture	Notes and related topics
Complete?	No value captured.	Default value is Yes.
Create From	Set to BFILE for Java objects created with:  USING BFILE ... Set to BLOB for Java objects created with:  USING BLOB ... Set to CLOB for Java objects created with:  USING CLOB ... Set to Null for Java objects created with:  USING ‘Key_for_LOB_Value’ Set to Null for Java source objects created with:  AS ...
Database User	No value captured.
BLOB Name	Value captured if the Java source/class/resource is derived from a LOB column, i.e. using either:
	• a subquery	For example, when capturing:  CREATE JAVA CLASS  USING BLOB SELECT My_BLOB FROM My_Table WHERE ID=My_Code the BLOB Name property is set to SELECT My_BLOB FROM My_Table WHERE ID=My_Code
	• or a key value.	For example, when capturing:  CREATE JAVA CLASS  USING ‘MyKey’ the BLOB Name property is set to MyKey
Directory	Value captured only if the Java source/class/resource is derived from an external BFILE. Note: A definition for the directory must exist in the repository.	For example, when capturing: CREATE JAVA CLASS USING BFILE (MY_DIR, 'My_Code.Class') This property is set to MY_DIR
File Name	Value captured if the Java source/class/resource is derived from an external BFILE.	For example, when capturing: CREATE JAVA CLASS USING BFILE (MY_DIR, 'My_Code.Class') This property is set to My_Code.Class
Resolve ?	Set to Yes if RESOLVE specified.	Not applicable to Java resource objects.
Force ?	Set to No if NOFORCE specified.	Not applicable to Java resource objects.
Name Resolution
Resolver Clause	Clause captured.
Scope
Global Synonym Name	Value captured based on the Short Name.
Scope	No value captured.
Replication
Replication Group	No value captured.
Documentation
Implementation Description	No value captured.
Implementation Notes	No value captured.
Repository Java source properties set during design capture from database

Property	Set during capture	Notes and related topics
Short Name	This property is derived from the NAMED clause. For example, when capturing:    CREATE JAVA SOURCE NAMED "Hello"... the Short Name property is set to HELLO	If necessary, the Short Name is truncated to 20 characters.
Name	The Name is set to the Short Name by default.
Purpose	No value captured.
Type	Set to Source.
Implementation Name	No value captured.
Planning	No values captured.	Default values used.
Invocation	No values captured.	Default values used.
Java
Java Block	No value captured.
Documentation
Release Notes	No value captured.
Description	No value captured.
Notes	No value captured.
Repository Java source implementation properties set during capture from database

Property	Set during capture	Notes and related topics
Complete?	No value captured.	Default value is Yes.
Create From	No value captured.
Database User	No value captured.
BLOB Name	No value captured.	No value captured.
Directory	No value captured.	No value captured.
File Name	No value captured.	No value captured.
Resolve ?	No value captured.	Default value is No.
Force ?	No value captured.	Default value is Yes.
Name Resolution
Resolver Clause	Clause captured.
Scope
Global Synonym Name	Value captured based on the Short Name.
Scope	No value captured.
Replication
Replication Group	No value captured.
Documentation
Implementation Description	No value captured.
Implementation Notes	No value captured.


About captured queue tables

Source database type:	Oracle8.1 database
System privileges:	Access to the queue table
Capture from database:	Yes
Capture from file:	No
Repository properties:	Queue table properties set during design capture
	Queue table implementation properties set during design capture
During design capture a queue table definition and queue table implementation is created in the repository. If the queue table is based on an Oracle type, an Oracle object type and Oracle object type implementation is also created.

By default database objects are captured into the same database user definition. To capture schema information associated with AQ objects, set the Use User Qualified Names for Advanced Queuing Objects preference to Yes.

Storage information for queue tables can also be captured.

Repository queue table properties set during design capture

Property	Set during capture	Notes and related topics
Name	Value captured.	Queue tables are not captured if a definition exists with the same name.
Oracle Type	If a queue table is based on an Oracle type, the corresponding Oracle object type is also captured.
Scalar Datatype	Captured as ‘RAW’, if the queue payload type is not an object type, i.e. specifies RAW.
Sort List	Value captured.
Multiple Consumers?	Value captured.
Message Grouping	Value captured.
Auto Commit ?	No value captured as it is not stored in the database.
Primary Instance	Value captured.
Secondary Instance	Value captured.
Compatible Database Version	Value captured.
Documentation
Comment	Value captured.
Description	No value captured.
Notes	No value captured.
User Help Text	No value captured.
Repository queue table implementation properties set during capture

Property	Set during capture	Notes and related topics
Complete?	No value captured.	Default value is Yes.
Database User of Oracle Type	If the QULUSR preference is set to Yes: • If the object type name is prefixed with <user>., this value is set to <user> • If no prefix exists, this value is left blank If the QULUSR preference is set to No, this value is also left blank.
Storage
Storage Definition	Value captured.
Tablespace	Value captured.
Init Trans	Value captured.
Max Trans	Value captured.
Percent Free	Value captured.
Percent Used	Value captured.
Documentation
Implementation Description	No value captured.
Implementation Notes	No value captured.


About captured persistent queues

Source database type:	Oracle8.1 database
System privileges:	Access to the queue
Capture from database:	Yes
Capture from file:	No
Repository properties:	Persistent queue properties set during design capture
	Persistent queue implementation properties set during design capture
During design capture a persistent queue definition and persistent queue implementation is created in the repository.  Note that queues are captured in the context of a database, not a user definition.

When queues are captured, queue table definitions and queue table implementations are also created in the repository. By default all database objects are captured into the same database user definition. To capture schema information associated with a queue table, set the Use User Qualified Names for Advanced Queuing Objects preference to Yes.

Security information for persistent queues can also be captured.

Repository persistent queue properties set during capture

Property	Set during capture	Notes and related topics
Name	Value captured.	Queues are not captured if a definition exists with the same name.
Queue Table	Value captured.	If the corresponding queue table does not exist in the Repository, the warning CDS-15317 is displayed.
Queue Type	Value captured.
Auto Commit ?	No value captured as it is not stored in the database.
Max Retries	Value captured.
Retry Delay	Value captured.
Retention Time	Value captured. Note: If the value is ‘Infinite’, this property remains null and the ‘Unlimited Retention Time’ property is set to Yes.	N/A for exception queues.
Unlimited Retention Time ?	Set to Yes if the value is ‘Infinite’, i.e. retention_time => DBMS_AQADM.INFINITE	N/A for exception queues.
Comment	Value captured.
Description	No value captured.
Notes	No value captured.
User Help Text	No value captured.
Repository persistent queue implementation properties set during capture

Property	Set during capture	Notes and related topics
Complete?	No value captured.	Default value is Yes.
Queue Table Database User	If the QULUSR preference is set to Yes, this property is set to the table OWNER. If the QULUSR preference is set to No, this property is set to the name of the Repository user definition into which database objects are being captured.
Max Retries	Value captured.
Retry Delay	Value captured.
Retention Time	Value captured. Note: If the value is ‘Infinite’, this property remains null and the ‘Unlimited Retention Time’ property is set to Yes.	N/A for exception queues.
Unlimited Retention Time ?	Set to Yes if the value is ‘Infinite’, i.e. retention_time => DBMS_AQADM.INFINITE	N/A for exception queues.
Documentation
Implementation Description	No value captured.
Implementation Notes	No value captured.
System privileges
Privilege Name	Set to the appropriate advanced queuing privilege, i.e. DEQUEUE ANY, ENQUEUE ANY or MANAGE ANY.
Database User / Role	Set to the user or role, specified in the grantee option.
With Admin Option ?	Value captured.
Grant queue privileges
Dequeue ?	Set to Yes if the queue privilege is set to DEQUEUE, or ALL.
Enqueue ?	Set to Yes if the queue privilege is set to ENQUEUE, or ALL.
Database User/ Role	Set to the user or role, specified in the grantee option.
With Grant Option ?	Value captured.


About captured non-persistent queues

Source database type:	Oracle8.1 database
System privileges:	Access to the queue
Capture from database:	Yes
Capture from file:	No
Repository properties:	Non-persistent queue properties set during design capture
	Non-persistent queue implementation properties set during design capture
During design capture a non-persistent queue definition and non-persistent queue implementation is created in the repository.  Note that queues are captured in the context of a database, not a user definition.

Security information for non-persistent queues can also be captured.

Repository non-persistent queue properties set during capture

Property	Set during capture	Notes and related topics
Name	Value captured.	Queues are not captured if a definition exists with the same name.
Multiple Consumers?	Value captured.
Comment	Value captured.
Description	No value captured.
Notes	No value captured.
User Help Text	No value captured.
Repository non-persistent queue implementation properties set during capture

Property	Set during capture	Notes and related topics
Complete?	No value captured.	Default value is Yes.
Documentation
Implementation Description	No value captured.
Implementation Notes	No value captured.
System privileges
Privilege Name	Set to the appropriate advanced queuing privilege, i.e. DEQUEUE ANY, ENQUEUE ANY or MANAGE ANY.
Database User / Role	Set to the user or role, specified in the grantee option.
With Admin Option ?	Value captured.
Grant queue privileges
Dequeue ?	Set to Yes if the queue privilege is set to DEQUEUE, or ALL.
Enqueue ?	Set to Yes if the queue privilege is set to ENQUEUE, or ALL.
Database User / Role	Set to the user or role, specified in the grantee option.
With Grant Option ?	Value captured.


About captured queue subscribers

Source database type:	Oracle8.1 database
System privileges:	Access to the subscriber
Capture from database:	Yes
Capture from file:	No
Repository properties:	Queue subscriber properties set during design capture
Subscribers cannot be captured independently, they are always captured with their respective queue implementation. Note that queues are captured in the context of a database, not a user definition.

Repository queue subscriber properties set during capture

Property	Set during capture	Notes and related topics
Name	Value captured.	Queue subscribers are not captured if a definition exists with the same name.
Address	Value captured. This can be: • a protocol specific address • or, for local subscribers the literal string: null
Protocol	No value captured.	Not currently used in the database.
Rule	Value captured.
Documentation
Description	No value captured.
Notes	No value captured.
User/Help Text	No value captured.


Constructs that cannot be captured

Database object names

The names of repository objects cannot exceed 30 characters. The name of a captured object whose name exceeds this limit is truncated to 30 characters.

Database objects with reserved names, e.g. SYSDATE cannot be stored in the repository and hence cannot be captured.

Schema names

The schema names of objects are not captured.

Line length

A limit of 32000 characters is imposed on the length of a single statement for error logging purposes.

If this limit is exceeded during the design capture process, a warning is logged. If a view expression or PL/SQL block statement exceeds this limit, an error is logged and the statement is not captured.

CREATE TABLE command

The CREATE TABLE AS SELECT syntax cannot be captured.

Datatypes

The datatype of a column must always be specified. Versions of the CREATE TABLE syntax that implies the column's datatype from a foreign key is not supported.

Constraints

Enable and Disable clauses are ignored when capturing constraints from file.

Foreign key constraints

If the name of the referenced column is omitted from a foreign key definition, the column name is assumed to have the same name as the foreign key column.

CREATE PROCEDURE

External routines specified using the AS EXTERNAL clause can not be captured. Note however, that in Oracle8.1 this clause has been deprecated and is supported for backward compatibility only. Oracle Corporation recommends that you use the AS LANGUAGE C syntax instead.

CREATE PUBLIC SYNONYM

Public synonyms are not captured.

CREATE SYNONYM

Synonyms on synonyms are not captured.

CREATE VIEW command

The view syntax CREATE VIEW <name> AS (SELECT <column_name> FROM <table_name>) where the SELECT statement is enclosed in parentheses is not supported. The opening parentheses is removed but the closing parenthesis is not. A workaround is to edit the captured view definition and delete the closing parenthesis.

Methods (for Oracle object types)

The SELF IN OUT parameter type is not supported and can not be captured from either database or file.

Advanced queuing objects

Advanced queuing objects can not be captured from files. However, they can be captured from an online database.

Partitions

Partitions defined within views or materialized views are not captured.


About Server Generator preferences

Related Topics

Server Generator preferences are options that influence the way databases are both generated and captured. Every preference has a default setting that will be used if the preference has not been set explicitly. Server Generator preferences can be set at the container level only. How

Note:	Server Generator does not  support the use of preference sets.

Server Generator preferences are grouped into these categories:

Capture - General	General options that are applied during database capture. They determine whether comments, grants, synonyms or table API triggers are captured.
Capture - Materialized Views	Options that determine how materialized views are captured.
Capture - Oracle Object Types	Options that determine how Oracle object types are captured.
Capture - PL/SQL Definitions	Options that determine how PL/SQL definitions are captured.
Capture - Tables	Options that determine how tables are captured.
Capture - Views	Options that determine how views are captured.
General	Options that are applied during both database generation and database capture.
Generate - General	Options that are applied during database generation.
Generate - Tables	Options that are applied during table generation.
Generate - TAPI	Options that are applied during Table API generation.
Generate - Views	Options that are applied during view generation.
Reconcile Report	Options that are applied when the reconcile reports is generated.


Server Generator preferences - organized by category

Related Topics

You can customize the way databases are both captured and generated by changing the initial settings of these Server Generator preferences.

Capture - General

Capture Comments	RECCOM
Capture Grants	RECGRT
Capture Synonyms	RECSYN
Capture TAPI Generated Triggers with Tables	DTAPIT
General

Use User Qualified Names for Advanced Queuing Objects	QULUSR
Generate - General

Generate All Possible Objects in Alphabetical Order	ALPHA
Generate Database Object Privileges with the Roles	GENGRO
Generate Database Object Privileges with the Users	GENGUS
Use Parsing Technology in order to Add Begin/End	PARSER
Generate - TAPI

Generate Date Modified and Modified By for Insertion	MODINS
Generate Constant Suffix for Repository User Defined Error Messages	USERDM
Generate - Views

Generate the creation of the Views with Force Clause	GENVFO
Generate - Tables

Drop Column, Constraint and Index action	DRPSAC
Capture - Materialized Views

Capture New Materialized View s	ADNEMV
Capture New Materialized View Elements - Default	DADNSM
Capture New Materialized View Columns	ADNCOM
Capture New Materialized View Check Constraints	ADNCKM
Capture New Materialized View Foreign Keys	ADNFKM
Capture New Materialized View Primary Keys	ADNPKM
Capture New Materialized View Unique Keys	ADNUKM
Capture New Materialized View Indexes	ADNINM
Capture New Materialized View Implementations	ADNMIM
Capture New Materialized Views - Warning Level	MVANWL
Capture New Materialized View Implementations - Warning Level	MIANWL
Update Materialized Views existing in the Repository	MVALRI
Update Secondary Elements existing in the Repository - Default	DSARIM
Update Columns Existing in the Repository	COARIM
Update Check Constraints Existing in the Repository	CKARIM
Update Foreign Keys existing in the Repository	FKARIM
Update Primary Keys existing in the Repository	PKARIM
Update Unique Keys existing in the Repository	UKARIM
Update Indexes existing in the Repository	INARIM
Update Materialized View Implementations existing in the Repository	MIMAIN
Update Materialized Views existing in the Repository - Warning Level	MVAIWL
Update Materialized View Implementations existing in the Repository - Warning Level	MIAIWL
Delete Secondary Elements not in the Database - Default	DDESFM
Delete Columns not in the Database	DECOFM
Delete Check Constraints not in the Database	DECKFM
Delete Foreign Keys not in the Database	DEFKFM
Delete Primary Keys not in the Database	DEPKFM
Delete Unique Keys not in the Database	DEUKFM
Delete Indexes not in the Database	DEINFM
Capture - Oracle Object Types

Capture New Oracle Object Types	ADNEOT
Capture New Oracle Object Type Attributes	ADNCOO
Capture New Oracle Object Types - Warning Level	OTANWL
Update Oracle Object Types existing in the Repository	OTALRI
Update Attributes existing in the Repository	COARIO
Update Oracle Object Types existing in the Repository - Warning Level	OTAIWL
Delete Attributes not in the Database	DECOFO
Capture - PL/SQL Definitions

Capture New PL/SQL Definitions	ADNEPL
Capture New PL/SQL Definition Elements - Default	DADNSP
Capture New PL/SQL Definition Arguments	ADNARP
Capture New PL/SQL Definition Implementations	ADNPIM
Capture New PL/SQL Definitions - Warning Level	PLANWL
Capture New PL/SQL Definition Implementations - Warning Level	PIANWL
Update PL/SQL Definitions existing in the Repository	PLALRI
Update Secondary Element existing in the Repository - Default	DSARIP
Update Arguments existing in the Repository	ARARIP
Update PL/SQL Definition Implementations existing in the Repository	PIMAIN
Update PL/SQL Definitions existing in the Repository - Warning Level	PLAIWL
Update PL/SQL Definition Implementations existing in the Repository - Warning Level	PIAIWL
Delete Secondary Elements not in the Database - Default	DDESFP
Delete Arguments not in the Database	DEARFP
Reconcile Report

Difference detail	RRDIFF
Objects option	RROBJ
Generation option	RROPT
Report level	RRREP
Capture - Tables

Capture New Tables	ADNEWT
Capture New Table Elements - Default	DADNST
Capture New Table Columns	ADNCOT
Capture New Table Check Constraints	ADNCKT
Capture New Table Foreign Keys	ADNFKT
Capture New Table Primary Keys	ADNPKT
Capture New Table Unique Keys	ADNUKT
Capture New Table Indexes	ADNINT
Capture New Table Implementations	ADNTIM
Capture New Tables - Warning Level	TANEWL
Capture New Table Implementations - Warning Level	TIANWL
Update Tables existing in the Repository	TALRIN
Update Secondary Elements existing in the Repository - Default	DSARIT
Update Columns existing in the Repository	COARIT
Update Check Constraints existing in the Repository	CKARIT
Update Foreign Keys existing in the Repository	FKARIT
Update Primary Keys existing in the Repository	PKARIT
Update Unique Keys existing in the Repository	UKARIT
Update Indexes existing in the Repository	INARIT
Update Table Implementations existing in the Repository	TIMAIN
Update Tables existing in the Repository - Warning Level	TAINWL
Update Table Implementations existing in the Repository - Warning Level	TIAIWL
Delete Secondary Elements not in the Database - Default	DDESFT
Delete Columns not in the Database	DECOFT
Delete Check Constraints not in the Database	DECKFT
Delete Foreign Keys not in the Database	DEFKFT
Delete Primary Keys not in the Database	DEPKFT
Delete Unique Keys not in the Database	DEUKFT
Delete Indexes not in the Database	DEINFT
Capture - Views

Capture New Views	ADNEWV
Capture New View Elements - Default	DADNSV
Capture New View Columns	ADNCOV
Capture New View Implementations	ADNVIM
Capture New Views - Warning Level	VANEWL
Capture New View Implementations - Warning Level	VIANWL
Update Views existing in the Repository	VALRIN
Update Secondary Elements existing in the Repository - Default	DSARIV
Update Columns existing in the Repository	COARIV
Update View Implementations existing in the Repository	VIMAIN
Update Views existing in the Repository - Warning Level	VAINWL
Update View Implementations existing in the Repository - Warning Level	VIAIWL
Delete Secondary Elements not in the Database - Default	DDESFV
Delete Columns not in the Database	DECOFV


Capture comments preference (RECCOM)
Capture comments (RECCOM)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - General

Use this preference to specify whether comments associated with database objects are to be captured, i.e. comments defined for tables, columns, materialized views or views.


Capture grants preference (RECGRT)
Capture grants (RECGRT)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - General

Use this preference to specify whether grants (associated with database objects) are to be captured.


Capture synonyms preference (RECSYN)
Capture synonyms (RECSYN)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - General

Use this preference to specify whether synonyms (of database objects) are to be captured.


Capture Generated Table API Triggers with Tables (DTAPIT)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - General

Use this preference to specify whether triggers that are generated during table API generation are to be captured at the same time as the associated tables.


Use User Qualified Names for Advanced Queuing Objects (QULUSR)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	General

Use this preference during database generation to specify whether the names of advanced queuing objects are to be prefixed with a database user name, i.e. <user_name>.<AQ_object_name>

During database capture, use this preference to specify whether the schema names of advanced queuing objects are captured, i.e. advanced queuing objects are created within their specified user definitions.

Note:	This preference also applies to Oracle object types when they are captured in the context of a queue table.


Generate All Possible Objects in Alphabetical Order (ALPHA)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	Generate - General

Use this preference to specify whether database objects are generated in alphabetical order. This preference applies to database objects that are generated via the menu options Generate→Generate Database from Server Model and Generate→Generate Database Administration Objects.

The options are:

Yes	Database objects are generated in alphabetical order.
No	The order in which database objects are generated is determined by Server Generator, based on internal repository ids.


Generate Database Object Privileges with the Roles (GENGRO)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	Generate - General

When generating roles, use this preference to specify whether database object privileges granted to the roles are generated at the same time.

The options are:

No	Database object privileges granted to roles are not processed during role generation. This is the default.
Yes	Appropriate database object GRANT statements are generated during role generation. Note:  To run the script, the owners of the database objects must have granted to you, object privileges with the GRANT OPTION.


Generate Database Object Privileges with the Users (GENGUS)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	Generate - General

When generating users, use this preference to specify whether database object privileges granted to the users are generated at the same time.

The options are:

No	Database object privileges granted to users are not processed during user generation.  This is the default.
Yes	Appropriate GRANT statements are generated during user generation. Note:  To run the script, the owners of the database objects must have granted to you, object privileges with the GRANT OPTION.


Use Parsing Technology in order to Add Begin/End (PARSER)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	Generate - General

Use this preference to specify whether PL/SQL code within PL/SQL definitions is parsed during generation. If parsing takes place, missing BEGIN and END statements can be added at the beginning and the end of a PL/SQL block, missing DECLARE statements can be added for triggers, etc. For further detail, see options below.

Note:	Multiple END statements can be added such that the number of BEGIN and END statements are the same.  However, it is only possible to add a single BEGIN statement.

The examples below show the DDL generated for the PL/SQL Block when this preference is set to ‘Yes’, for a PL/SQL function definition named GET_BAL:

PL/SQL Block property contains:	Generated code:
SELECT balance INTO acc_bal FROM accounts WHERE account_id = acc_no; RETURN(acc_bal);	BEGIN SELECT balance INTO acc_bal FROM accounts WHERE account_id = acc_no; RETURN(acc_bal); END;
BEGIN SELECT balance INTO acc_bal FROM accounts WHERE account_id = acc_no; RETURN(acc_bal);	BEGIN SELECT balance INTO acc_bal FROM accounts WHERE account_id = acc_no; RETURN(acc_bal); END;
SELECT balance INTO acc_bal FROM accounts WHERE account_id = acc_no; RETURN(acc_bal); END;	BEGIN SELECT balance INTO acc_bal FROM accounts WHERE account_id = acc_no; RETURN(acc_bal); END;
The options are:

Yes	Code within the PL/SQL Block property is parsed during generation and if appropriate, missing BEGIN/END statements, etc. are added. Procedures/Functions: - Missing BEGIN/ENDs added - Missing ENDs added - Missing BEGINs added, but only if there are no declarations Package Specifications: - Missing ENDs added Package Body: - Missing BEGIN/ENDs added - Missing ENDs added - Missing BEGINs added, but only if there are no declarations - Private declarations specified within the PL/SQL Block property are placed at the top of the package body Triggers: - Missing BEGIN/ENDs added - Missing ENDs added - Missing BEGINs added, but only if there are no declarations - Missing DECLAREs added
No	No parsing takes place. Generation time decreases. Procedures/Functions/Triggers: - No code changes. Package Specifications: - Missing ENDs added Package Body: - Whole PL/SQL Block placed at the bottom of the package body


Generate Date Modified and Modified By for Insertion (MODINS)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Generate - TAPI

Use this preference to specify whether Date Modified and Modified By information (on server derived columns) is required when a row is inserted on the database via generated Table API.

Note:	If the server derived column is mandatory, this preference must be set to Yes.

The options are:

No	The Table API only generates Date Modified and Modified By information when a row is updated on the database.
Yes	Date Modified and Modified By information is generated when a new row is inserted on the database and when rows are updated.


Generate Constant Suffix for Repository User Defined Error Messages (USERDM)

Related Topics

Default:	No value

Values:	Up to 5 characters

Levels:	Container

Category: 	Generate - TAPI

Use this preference to specify a suffix for the CONSTANT generated from user-defined error messages.

Specifying this preference avoids CONSTANT naming conflicts in generated Table API code. Conflict can occur if table primary keys are derived from sequences and the names of these sequences are the identical to any of the table constraints.

For example:

Preference	CONSTANT generated for user defined error messages
No value	PK_EMP CONSTANT VARCHAR2(240) := 'Employee ID must be unique’
Suffix set to _MSG	PK_EMP_MSG CONSTANT VARCHAR2(240) := 'Employee ID must be unique’
Note:	If any references exist to user defined error messages within custom Table API logic, ensure that they are updated once this preference is set.


Generate the creation of the Views with Force Clause (GENVFO)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Generate - Views

Use this preference to specify whether CREATE VIEW statements are generated with the FORCE clause, i.e. CREATE FORCE VIEW …

The FORCE clause allows views to be created on the database regardless of whether the view's base tables or the referenced object types exist, or the owner of the schema containing the view has privileges on them. Note however, that these conditions must be true before any SELECT, INSERT, UPDATE, or DELETE statements can be issued against the view.

If this preference is set to No, CREATE VIEW statements are generated. Using this syntax, views can only be created on the database if the base tables exist and the owner of the schema containing the view has privileges on them.

The options are:

Yes	CREATE FORCE VIEW statements are generated for views.
No	CREATE VIEW statements are generated for views.


Drop Column, Constraint and Index action (DRPSAC)

Related Topics

Default:	Ask which secondary elements are to be dropped

Values:	Always drop secondary elements, Ask which secondary elements are to be dropped, Never drop secondary elements

Levels:	Container

Category: 	Generate - Tables

Use this preference to specify whether you want to be asked if DDL should be generated that will drop tables and/or alter (drop and recreate) index-based objects.

This preference applies when:

-	there are secondary elements (columns and constraints) in the database that are not in the repository and it is possible to drop them

-	there are index-based objects that do not match the database design and it is possible to drop and recreate ("alter") them.

The options are:

Always drop secondary elements	Without warning during the generation process, DDL will be generated that drops or alters the secondary elements.
Ask which secondary elements are to be dropped	During generation of DDL, you will be asked to specify which secondary elements, if any, you wish to drop or alter.
Never drop secondary elements	The generated DDL will not include any statements to drop or alter the secondary elements. A warning message will be issued for each column, constraint and index-based object that exists in the database but not in the repository.


Capture New Materialized Views (ADNEMV)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether new materialized view definitions can be created in the repository during database capture.

The options are:

Yes	During database capture, new materialized views can be created in the repository.
No	Do not capture new materialized views.


Capture New Materialized View Elements - Default (DADNSM)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to define the default behavior when capturing new secondary elements of materialized views. For example new columns, check constraints, foreign keys, etc. associated with a materialized view.

You can use other preferences to override this default for individual secondary elements. See columns, check constraints, foreign keys, primary keys, unique keys and indexes.

The options are:

Yes	During database capture, the default behavior is to create new materialized view elements in the repository.
No	The default behavior is not to capture new materialized view elements.


Add New Materialized View Columns (ADNCOM)
Capture New Materialized View Columns (ADNCOM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether new column definitions (for existing materialized views) can be created in the repository during database capture.

The options are:

Yes	During database capture, new materialized view columns can be created in the repository.
No	Do not capture new materialized view columns.
Default	The behavior is determined by the preference Capture New Materialized View Elements - Default (DADNSM).


Capture New Materialized View Check Constraints (ADNCKM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether new check constraint definitions (for existing materialized views) can be created in the repository during database capture.

The options are:

Yes	During database capture, new materialized view check constraints can be created in the repository.
No	Do not capture new materialized view check constraints.
Default	The behavior is determined by the preference Capture New Materialized View Elements - Default (DADNSM).


Capture New Materialized View Foreign Keys (ADNFKM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether new foreign key definitions (for existing materialized views) can be created in the repository during database capture.

The options are:

Yes	During database capture, new materialized view foreign keys can be created in the repository.
No	Do not capture new materialized view foreign keys.
Default	The behavior is determined by the preference Capture New Materialized View Elements - Default (DADNSM).


Capture New Materialized View Primary Keys (ADNPKM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether new primary key definitions (for existing materialized views) can be created in the repository during database capture.

The options are:

Yes	During database capture, new materialized view primary keys can be created in the repository.
No	Do not capture new materialized view primary keys.
Default	The behavior is determined by the preference Capture New Materialized View Elements - Default (DADNSM).


Capture New Materialized View Unique Keys (ADNUKM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether new unique key definitions (for existing materialized views) can be created in the repository during database capture.

The options are:

Yes	During database capture, new materialized view unique keys can be created in the repository.
No	Do not capture new materialized view unique keys.
Default	The behavior is determined by the preference Capture New Materialized View Elements - Default (DADNSM).


Capture New Materialized View Indexes (ADNINM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether new index definitions (for existing materialized views) can be created in the repository during database capture.

The options are:

Yes	During database capture, new materialized view indexes can be created in the repository.
No	Do not capture new materialized view indexes.
Default	The behavior is determined by the preference Capture New Materialized View Elements - Default (DADNSM).


Capture New Materialized View Implementations (ADNMIM)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether new implementations for existing materialized view definitions can be created in the repository during database capture.

Note: 	View implementations are always created when capturing new materialized views.

The options are:

Yes	During database capture, new materialized view implementations can be created in the repository.
No	Do not capture new materialized view implementations.


Capture New Materialized Views - Warning Level (MVANWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify the type of message displayed during database capture,  when a new materialized view definition is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Capture New Materialized View Implementations - Warning Level (MIANWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify the type of message displayed during database capture,  when a new materialized view implementation definition is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Materialized View Already in Repos (MVALRI)
Update Materialized Views existing in the Repository (MVALRI)

Related Topics

Default:	Do Not Merge but use Secondary Element Rules
Values:	Do Not Merge but use Secondary Element Rules, Merge and use Secondary Element Rules, Create a new Element, No Action Taken
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify whether materialized view definitions existing in the repository can be updated during database capture.

The options are:

No Action Taken	Existing materialized view definitions remain unchanged.
Merge and use  Secondary Element Rules	Existing materialized view definitions are changed according to the new information coming from the database. Other preferences determine whether any changes to secondary elements of materialized views are captured. See Update Secondary Elements existing in the Repository - Default (DSARIM).
Do Not Merge but use Secondary Element Rules	Existing materialized view definitions remain unchanged. Other preferences determine whether changes to secondary elements of materialized views are captured. See Update Secondary Elements existing in the Repository - Default (DSARIM).
Create a new Element	A new materialized view definition is created with a unique name, i.e. <source object name><number>. Any secondary elements captured from the database are created on the new materialized view definition.


Update Secondary Elements existing in the Repository (DSARIM)
Update Secondary Elements existing in the Repository - Default (DSARIM)

Related Topics

Default:	No Action Taken
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to define the default behavior when updating existing secondary elements of materialized views during database capture, i.e. columns, check constraints, foreign keys, etc. associated with materialized views.

You can use other preferences to override this default for individual secondary elements. See columns, check constraints, foreign keys, primary keys, unique keys, and indexes.

The options are:

No Action Taken	During database capture, the default behavior is that existing secondary elements of materialized views remain unchanged.
Merge the Secondary Element	Existing secondary element definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing secondary element definitions are deleted from the repository and replaced with new secondary element definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Columns existing in the Repository (COARIM)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify whether existing columns of materialized view definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing column definitions for materialized views are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIM).
Merge the Secondary Element	Existing column definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing column definitions are deleted from the repository and replaced with new column definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Check Constraints existing in the Repository (CKARIM)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify whether existing check constraints of materialized view definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing check constraint definitions for materialized views are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIM).
Merge the Secondary Element	Existing check constraint definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing check constraint definitions are deleted from the repository and replaced with new check constraint definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Foreign Keys existing in the Repository (FKARIM)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify whether existing foreign keys of materialized view definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing foreign key definitions for materialized views are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIM).
Merge the Secondary Element	Existing foreign key definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing foreign key definitions are deleted from the repository and replaced with new foreign key definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Primary Keys existing in the Repository (PKARIM)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify whether existing primary keys of materialized view definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing primary key definitions for materialized views are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIM).
Merge the Secondary Element	Existing primary key definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing primary key definitions are deleted from the repository and replaced with new primary key definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Unique Keys existing in the Repository (UKARIM)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify whether existing unique keys of materialized view definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing unique key definitions for materialized views are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIM).
Merge the Secondary Element	Existing unique key definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing unique key definitions are deleted from the repository and replaced with new unique key definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Indexes existing in the Repository (INARIM)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify whether existing indexes of materialized view definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing index definitions for materialized views are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIM).
Merge the Secondary Element	Existing index definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing index definitions are deleted from the repository and replaced with new index definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Materialized View Implementations existing in the Repository (MIMAIN)

Related Topics

Default:	Merge the Secondary Element
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify whether existing materialized view implementations can be updated during database capture.

The options are:

No Action Taken	During database capture existing materialized view implementations are not updated, they remain unchanged.
Merge the Secondary Element	Existing materialized view implementations are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing materialized view implementations are deleted from the repository and replaced with new materialized view implementations using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Materialized Views existing in the Repository - Warning Level (MVAIWL)

Related Topics

Default:	Warning generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify the type of message displayed during database capture,  when an existing materialized view definition is to be updated.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Update Materialized View Implementations existing in the Repository - Warning Level (MIAIWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Materialized Views
Use this preference to specify the type of message displayed during database capture,  when an existing materialized view implementation is to be updated.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Delete Secondary Elements not in the Database - Default (DDESFM)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to define the default behavior when deleting secondary elements of materialized views from the repository, during database capture. For example columns, check constraints, foreign keys, etc. no longer associated with a materialized view.

You can use other preferences to override this default for individual secondary elements. See columns, check constraints, foreign keys, primary keys, unique keys, and indexes.

The options are:

No	During database capture, the default behavior is not to delete materialized view elements that are no longer in the database.
Yes	The default behavior is to delete materialized view elements that are no longer in the database.


Delete Columns not in the Database (DECOFM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether column definitions (for materialized views) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, materialized view columns can be deleted from the repository if they no longer exist in the source database.
No	Materialized view columns may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFM).


Delete Check Constraints not in the Database (DECKFM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether check constraint definitions (for materialized views) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, materialized view check constraints can be deleted from the repository if they no longer exist in the source database.
No	Materialized view check constraints may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFM).


Delete Foreign Keys not in the Database (DEFKFM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether foreign key definitions (for materialized views) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, materialized view foreign keys can be deleted from the repository if they no longer exist in the source database.
No	Materialized view foreign keys may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFM).


Delete Primary Keys not in the Database (DEPKFM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether primary key definitions (for materialized views) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, materialized view primary keys can be deleted from the repository if they no longer exist in the source database.
No	Materialized view primary keys may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFM).


Delete Unique Keys not in the Database (DEUKFM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether unique key definitions (for materialized views) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, materialized view unique keys can be deleted from the repository if they no longer exist in the source database.
No	Materialized view unique keys may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFM).


Delete Indexes not in the Database (DEINFM)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Materialized Views

Use this preference to specify whether index definitions (for materialized views) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, materialized view indexes can be deleted from the repository if they no longer exist in the source database.
No	Materialized view indexes may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFM).


Capture New Oracle Object Types (ADNEOT)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Oracle Object Types

Use this preference to specify whether new Oracle object type definitions can be created in the repository during database capture.

The options are:

Yes	During database capture, new Oracle object types can be created in the repository.
No	Do not capture new Oracle object types.


Capture New Oracle Object Type Attributes (ADNCOO)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Oracle Object Types

Use this preference to specify whether new attribute definitions (for existing Oracle object types) can be created in the repository during database capture.

The options are:

Yes	During database capture, new Oracle object type attributes can be created in the repository.
No	Do not capture new Oracle object type columns.


Capture New Oracle Object Types - Warning Level (OTANWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Oracle Object Types
Use this preference to specify the type of message displayed during database capture,  when a new Oracle object type definition is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Update Oracle Object Types existing in the Repository (OTALRI)

Related Topics

Default:	Do Not Merge but use Secondary Element Rules
Values:	Do Not Merge but use Secondary Element Rules, Merge and use Secondary Element Rules, Create a new Element, No Action Taken
Levels:	Container
Category:	Capture - Oracle Object Types
Use this preference to specify whether Oracle object type definitions existing in the repository can be updated during database capture.

The options are:

No Action Taken	Existing Oracle object type definitions remain unchanged.
Merge and use  Secondary Element  Rules	Existing Oracle object type definitions are changed according to the new information coming from the database. Another preference determines whether changes to Oracle object type attributes are captured. See Update Attributes existing in the Repository (COARIO).
Do Not Merge but use Secondary Element  Rules	Existing Oracle object type definitions remain unchanged. Another preference determines whether changes to Oracle object type attributes are captured. See Update Attributes existing in the Repository (COARIO).
Create a new Element	A new Oracle object type definition is created with a unique name, i.e. <source object name><number>. Any secondary elements are created on the new Oracle object type.


Update Attributes existing in the Repository (COARIO)

Related Topics

Default:	No Action Taken
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Oracle Object Types
Use this preference to specify whether existing attributes of Oracle object type definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing attribute definitions for Oracle object types are not updated, they remain unchanged.
Merge the Secondary Element	Existing attribute definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing attribute definitions are deleted from the repository and replaced with new attribute definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Oracle Object Types existing in the Repository - Warning Level (OTAIWL)

Related Topics

Default:	Warning generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Oracle Object Types
Use this preference to specify the type of message displayed during database capture,  when an existing Oracle object type definition is to be updated.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Delete Attributes not in the Database (DECOFO)

Related Topics

Default:	No

Values:	No, Yes

Levels:	Container

Category: 	Capture - Oracle Object Types

Use this preference to specify whether attribute definitions (for Oracle object types) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, Oracle object type attributes can be deleted from the repository if they no longer exist in the source database.
No	Oracle object type attributes may not be deleted during database capture.


Capture New PL/SQL Definitions (ADNEPL)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - PL/SQL Definitions

Use this preference to specify whether new PL/SQL definitions, i.e. PL/SQL functions, procedures, and packages, can be created in the repository during database capture.

The options are:

Yes	During database capture, new PL/SQL definitions can be created in the repository.
No	Do not capture new PL/SQL definitions.


Capture New PL/SQL Definition Elements - Default (DADNSP)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - PL/SQL Definitions

Use this preference to define the default behavior when capturing new secondary elements of PL/SQL definitions. For example, new arguments associated with a PL/SQL definition.

You can use another preference to override this default for arguments.

The options are:

Yes	During database capture, the default behavior is to create new PL/SQL definition elements in the repository.
No	The default behavior is not to capture new PL/SQL definition elements.


Capture New PL/SQL Definition Arguments (ADNARP)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - PL/SQL Definitions

Use this preference to specify whether new argument definitions (for existing PL/SQL definitions) can be created in the repository during database capture.

The options are:

Yes	During database capture, new PL/SQL definition arguments can be created in the repository.
No	Do not capture new PL/SQL definition arguments.
Default	The behavior is determined by the preference Capture New PL/SQL Definition Elements - Default (DADNSP).


Capture New PL/SQL Implementationa (ADNPIM)
Capture New PL/SQL Implementations (ADNPIM)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - PL/SQL Definitions

Use this preference to specify whether new PL/SQL implementations (for existing PL/SQL definitions) can be created in the repository during database capture, i.e. function implementations, package implementations and procedure implementations.

Note: 	PL/SQL implementations are always created when capturing new PL/SQL definitions.

The options are:

Yes	During database capture, new PL/SQL implementations can be created in the repository.
No	Do not capture new PL/SQL implementations.


Capture New PL/SQL Definitions - Warning Level (PLANWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - PL/SQL Definitions
Use this preference to specify the type of message displayed during database capture,  when a new PL/SQL definition is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Capture New PL/SQL Implementations - Warning Level (PIANWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - PL/SQL Definitions
Use this preference to specify the type of message displayed during database capture,  when a new PL/SQL implementation is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Update PL/SQL Definitions existing in the Repository (PLALRI)

Related Topics

Default:	Merge but use Secondary Element Rules
Values:	Do Not Merge but use Secondary Element Rules, Merge and use Secondary Element Rules, Create a new Element, No Action Taken
Levels:	Container
Category:	Capture - PL/SQL Definitions
Use this preference to specify whether PL/SQL definitions existing in the repository can be updated during database capture.

The options are:

No Action Taken	Existing PL/SQL definitions remain unchanged.
Merge and use  Secondary Element Rules	Existing PL/SQL definitions are changed according to the new information coming from the database. Other preferences determine whether any changes to secondary elements of PL/SQL definitions are captured. See Update Secondary Elements existing in the Repository - Default (DSARIP).
Do Not Merge but use Secondary Element Rules	Existing PL/SQL definitions remain unchanged. Other preferences determine whether changes to secondary elements of PL/SQL definitions are captured. See Update Secondary Elements existing in the Repository - Default (DSARIP).
Create a new Element	A new PL/SQL definition is created with a unique name, i.e. <source object name><number>. Any secondary elements are created on the new PL/SQL definition.


Update Secondary Elements existing in the Repository - Default (DSARIP)

Related Topics

Default:	Merge the Secondary Element
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - PL/SQL Definitions
Use this preference to define the default behavior when updating existing secondary elements of PL/SQL definitions during database capture, i.e. arguments.

You can use another preference to override this default for arguments.

The options are:

No Action Taken	During database capture, the default behavior is that existing secondary elements of PL/SQL definitions remain unchanged.
Merge the Secondary Element	Existing secondary element definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing secondary element definitions are deleted from the repository and replaced with new secondary element definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Arguments existing in the Repository (ARARIP)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - PL/SQL Definitions
Use this preference to specify whether existing arguments of PL/SQL definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing arguments of PL/SQL definitions are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIP).
Merge the Secondary Element	Existing argument definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing argument definitions are deleted from the repository and replaced with new argument definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update PL/SQL Implementations existing in the Repository (PIMAIN)

Related Topics

Default:	Merge the Secondary Element
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - PL/SQL Definitions
Use this preference to specify whether existing PL/SQL implementations can be updated during database capture.

The options are:

No Action Taken	During database capture existing PL/SQL implementations are not updated, they remain unchanged.
Merge the Secondary Element	Existing PL/SQL implementations are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing PL/SQL implementations are deleted from the repository and replaced with new PL/SQL implementations using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update PL/SQL Definitions existing in the Repository - Warning Level (PLAIWL)

Related Topics

Default:	Warning generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - PL/SQL Definitions
Use this preference to specify the type of message displayed during database capture,  when an existing PL/SQL definition is to be updated.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Update PL/SQL Implementations existing in the Repository - Warning Level (PIAIWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - PL/SQL Definitions
Use this preference to specify the type of message displayed during database capture,  when an existing PL/SQL implementation is to be updated, i.e. a function implementation, package implementation or procedure implementation.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Delete Secondary Elements not in the Database - Default (DDESFP)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	Capture - PL/SQL Definitions

Use this preference to define the default behavior when deleting secondary elements of PL/SQL definitions from the repository, during database capture. For example, arguments no longer associated with a PL/SQL definition.

You can use another preference to override this default for arguments.

The options are:

No	During database capture, the default behavior is not to delete PL/SQL definition elements that are no longer in the source database.
Yes	The default behavior is to delete PL/SQL definition elements that are no longer in the database.


Delete Arguments not in the Database (DEARFP)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - PL/SQL Definitions

Use this preference to specify whether argument definitions (for PL/SQL definitions) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, PL/SQL definition arguments can be deleted from the repository if they no longer exist in the source database.
No	PL/SQL definition arguments may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFP)


Reconcile Report - Difference detail (RRDIFF)

Related Topics

Default:	Definition and Implementation

Values:	Definition and Implementation, Implementation, Definition

Levels:	Container

Category: 	Reconcile Report

Use this preference to specify whether the reconcile report contains information relating to base database object definitions (e.g. table definitions), user-specific implementations (e.g. table implementations), or both.


Reconcile Report Objects option (RROBJ)
Reconcile Report - Objects option (RROBJ)

Related Topics

Default:	Primary Elements and Secondary Elements
Values:	Primary Elements and Secondary Elements, Primary Elements Only
Levels:	Container
Category:	Reconcile Report
Use this preference to specify whether the reconcile report contains information relating to primary database objects only (e.g. tables, views, materialized views, etc.) or whether secondary elements are also included (e.g. for tables this would include columns, check constraints, foreign keys etc.)


Reconcile Report - Generation option (RROPT)

Related Topics

Default:	Report and Generation
Values:	Report and Generation, Report Only, No Report
Levels:	Container
Category:	Reconcile Report
Use this preference to specify whether a reconcile report is required and when to generate the corresponding DDL.

The options are:

Report and Generation	Generate a reconcile report and then generate the required DDL.
Report Only	Generate a reconcile report only.
No Report	Generate the DDL only. No reconcile report is required.


Reconcile Report - Report level (RRREP)

Related Topics

Default:	Differences and Sameness
Values:	Differences and Sameness, Only Differences
Levels:	Container
Category:	Reconcile Report
Use this preference to specify whether the reconcile report only contains information relating to differences found between database objects in the repository and the corresponding database objects in the target database.

If preferred, database objects found to be the same can also be reported.


Capture New Tables (ADNEWT)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether new table definitions (relational and object) can be created in the repository during database capture.

The options are:

Yes	During database capture, new table definitions can be created in the repository.
No	Do not capture new tables.


Capture New Table Elements - Default (DADNST)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to define the default behavior when capturing new secondary elements of tables (relational or object). For example new columns, check constraints, foreign keys, etc. associated with a relational table.

You can use other preferences to override this default for individual secondary elements. See columns, check constraints, foreign keys, primary keys, unique keys, and indexes.

The options are:

Yes	During database capture, the default behavior is to create new table elements in the repository.
No	The default behavior is not to capture new table elements.


Capture New Table Columns (ADNCOT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether new column definitions (for relational tables) can be created in the repository during database capture.

The options are:

Yes	During database capture, new column definitions can be created in the repository.
No	Do not capture new columns.
Default	The behavior is determined by the preference Capture New Table Elements - Default (DADNST).


Capture New Table Check Constraints (ADNCKT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether new check constraint definitions (for tables) can be created in the repository during database capture.

The options are:

Yes	During database capture, new check constraint definitions can be created in the repository.
No	Do not capture new table check constraints.
Default	The behavior is determined by the preference Capture New Table Elements - Default (DADNST).


Capture New Table Foreign Keys (ADNFKT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether new foreign key definitions (for existing relational tables) can be created in the repository during database capture.

The options are:

Yes	During database capture, new foreign key definitions can be created in the repository.
No	Do not capture new table foreign keys.
Default	The behavior is determined by the preference Capture New Table Elements - Default (DADNST).


Capture New Table Primary Keys (ADNPKT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether new primary key definitions (for existing relational tables) can be created in the repository during database capture.

The options are:

Yes	During database capture, new primary key definitions can be created in the repository.
No	Do not capture new table primary keys.
Default	The behavior is determined by the preference Capture New Table Elements - Default (DADNST).


Capture New Table Unique Keys (ADNUKT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether new unique key definitions (for existing relational tables) can be created in the repository during database capture.

The options are:

Yes	During database capture, new unique key definitions can be created in the repository.
No	Do not capture new table unique keys.
Default	The behavior is determined by the preference Capture New Table Elements - Default (DADNST).


Capture New Table Indexes (ADNINT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether new index definitions (for existing relational tables) can be created in the repository during database capture.

The options are:

Yes	During database capture, new index definitions can be created in the repository.
No	Do not capture new table indexes.
Default	The behavior is determined by the preference Capture New Table Elements - Default (DADNST).


Capture New Table Implementations (ADNTIM)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether new implementations for existing table definitions can be created in the repository during database capture.

Note: 	Table implementations are always created when capturing new tables.

The options are:

Yes	During database capture, new table implementation definitions can be created in the repository.
No	Do not capture new table implementations.


Capture New Tables - Warning Level (TANEWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Tables
Use this preference to specify the type of message displayed during database capture,  when a new table definition (relational or object) is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Capture New Table Implementations - Warning Level (TIANWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Tables
Use this preference to specify the type of message displayed during database capture,  when a new table implementation is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Update Tables existing in the Repository (TALRIN)

Related Topics

Default:	Do Not Merge but use Secondary Element Rules
Values:	Do Not Merge but use Secondary Element Rules, Merge and use Secondary Element Rules, Create a new Element, No Action Taken
Levels:	Container
Category:	Capture - Tables
Use this preference to specify whether table definitions (relational or object) existing in the repository can be updated during database capture.

The options are:

No Action Taken	Existing table definitions remain unchanged.
Merge and use  Secondary Element Rules	Existing table definitions are changed according to the new information coming from the database. Other preferences determine whether any changes to secondary elements of tables are captured. See Update Secondary Elements existing in the Repository - Default (DSARIT).
Do Not Merge but use Secondary Element Rules	Existing table definitions remain unchanged. Other preferences determine whether changes to secondary elements of tables are captured. See Update Secondary Elements existing in the Repository - Default (DSARIT).
Create a new Element	A new table definition is created with a unique name, i.e. <source object name><number>. Any secondary elements are created on the new table definition.


Update Secondary Elements existing in the Repository - Default (DSARIT)

Related Topics

Default:	No Action Taken
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Tables
Use this preference to define the default behavior when updating existing secondary elements of tables (relational or object) during database capture. For example, columns, check constraints, foreign keys, etc. associated with relational tables.

You can use other preferences to override this default for individual secondary elements. See columns, check constraints, foreign keys, primary keys, unique keys, and indexes.

The options are:

No Action Taken	During database capture, the default behavior is that existing secondary elements of tables remain unchanged.
Merge the Secondary Element	Existing secondary element definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing secondary element definitions are deleted from the repository and replaced with new secondary element definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Columns existing in the Repository (COARIT)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Tables
Use this preference to specify whether existing columns of relational table definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing column definitions are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIT).
Merge the Secondary Element	Existing column definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing column definitions are deleted from the repository and replaced with new column definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Check Constraints existing in the Repository (CKARIT)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Tables
Use this preference to specify whether existing check constraints of table definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing check constraint definitions for tables are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIT).
Merge the Secondary Element	Existing check constraint definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing check constraint definitions are deleted from the repository and replaced with new check constraint definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Foreign Keys existing in the Repository (FKARIT)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Tables
Use this preference to specify whether existing foreign keys of relational table definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing foreign key definitions for tables are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIT).
Merge the Secondary Element	Existing foreign key definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing foreign key definitions are deleted from the repository and replaced with new foreign key definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Primary Keys existing in the Repository (PKARIT)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Tables
Use this preference to specify whether existing primary keys of relational table definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing primary key definitions for tables are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIT).
Merge the Secondary Element	Existing primary key definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing primary key definitions are deleted from the repository and replaced with new primary key definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Unique Keys existing in the Repository (UKARIT)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Tables
Use this preference to specify whether existing unique keys of relational table definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing unique key definitions for tables are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIT).
Merge the Secondary Element	Existing unique key definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing unique key definitions are deleted from the repository and replaced with new unique key definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Indexes existing in the Repository (INARIT)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Tables
Use this preference to specify whether existing indexes of relational table definitions can be updated during database capture.

The options are:

No Action Taken	During database capture existing index definitions for tables are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIT).
Merge the Secondary Element	Existing index definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing index definitions are deleted from the repository and replaced with new index definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Table Implementations existing in the Repository (TIMAIN)

Related Topics

Default:	Merge the Secondary Element
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Tables
Use this preference to specify whether existing table implementations can be updated during database capture.

The options are:

No Action Taken	During database capture existing table implementations are not updated, they remain unchanged.
Merge the Secondary Element	Existing table implementations are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing table implementations are deleted from the repository and replaced with new table implementations using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Tables existing in the Repository - Warning Level (TAINWL)

Related Topics

Default:	Warning generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Tables
Use this preference to specify the type of message displayed during database capture,  when an existing table definition is to be updated.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Update Table Implementations existing in the Repository - Warning Level (TIAIWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Tables
Use this preference to specify the type of message displayed during database capture,  when an existing table implementation is to be updated.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Delete Secondary Elements not in the Database - Default (DDESFT)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to define the default behavior when deleting secondary table elements from the repository, during database capture. For example columns, check constraints, foreign keys, etc. no longer associated with a relational table definition.

You can use other preferences to override this default for individual secondary elements. See columns, check constraints, foreign keys, primary keys, unique keys, and indexes.

The options are:

No	During database capture, the default behavior is not to delete table elements that are no longer in the source database.
Yes	The default behavior is to delete table elements that are no longer in the database.


Delete Columns not in the Database (DECOFT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether column definitions (of tables) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, table columns can be deleted from the repository if they no longer exist in the source database.
No	Columns of tables may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFT).


Delete Check Constraints not in the Database (DECKFT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether check constraint definitions (of tables) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, table check constraints can be deleted from the repository if they no longer exist in the source database.
No	Table check constraints may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFT).


Delete Foreign Keys not in the Database (DEFKFT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether foreign key definitions (of relational tables) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, table foreign keys can be deleted from the repository if they no longer exist in the source database.
No	Table foreign keys may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFT).


Delete Primary Keys not in the Database (DEPKFT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether primary key definitions (of relational tables) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, table primary keys can be deleted from the repository if they no longer exist in the source database.
No	Table primary keys may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFT).


Delete Unique Keys not in the Database (DEUKFT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether unique key definitions (of relational tables) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, table unique keys can be deleted from the repository if they no longer exist in the source database.
No	Table unique keys may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFT).


Delete Indexes not in the Database (DEINFT)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Tables

Use this preference to specify whether index definitions (for relational tables) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, table indexes can be deleted from the repository if they no longer exist in the source database.
No	Table indexes may not be deleted during database capture.
Default	The behavior is determined by the preference Delete Secondary Elements not in the Database - Default (DDESFT).


Capture New Views (ADNEWV)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Views

Use this preference to specify whether new view definitions (relational and object) can be created in the repository during database capture.

The options are:

Yes	During database capture, new view definitions can be created in the repository.
No	Do not capture new views.


Capture New View Elements - Default (DADNSV)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Views

Use this preference to define the default behavior when capturing new secondary elements of views (relational or object). For example new columns associated with a relational view.

You can use another preference to override this default for columns.

The options are:

Yes	During database capture, the default behavior is to create new view elements in the repository.
No	The default behavior is not to capture new view elements.


Capture New View Columns (ADNCOV)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Views

Use this preference to specify whether new column definitions (for existing views) can be created in the repository during database capture.

The options are:

Yes	During database capture, new column definitions can be created in the repository.
No	Do not capture new columns.
Default	The behavior is determined by the preference Capture New View Elements - Default (DADNSV)


Capture New View Implementations (ADNVIM)

Related Topics

Default:	Yes

Values:	Yes, No

Levels:	Container

Category: 	Capture - Views

Use this preference to specify whether new implementations for existing view definitions can be created in the repository during database capture.

Note: 	View implementations are always created when capturing new views.

The options are:

Yes	During database capture, new view implementations can be created in the repository.
No	Do not capture new view implementations.


Capture New Views - Warning Level (VANEWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Views
Use this preference to specify the type of message displayed during database capture,  when a new view definition (relational or object) is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Capture New View Implementations - Warning Level (VIANWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Views
Use this preference to specify the type of message displayed during database capture,  when a new view implementation is to be created in the repository.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Update Views existing in the Repository (VALRIN)

Related Topics

Default:	Do Not Merge but use Secondary Element Rules
Values:	Do Not Merge but use Secondary Element Rules, Merge and use Secondary Element Rules, Create a new Element, No Action Taken
Levels:	Container
Category:	Capture - Views
Use this preference to specify whether view definitions (relational or object) existing in the repository can be updated during database capture.

The options are:

No Action Taken	Existing view definitions remain unchanged.
Merge and use  Secondary Element Rules	Existing view definitions are changed according to the new information coming from the database. Other preferences determine whether any changes to secondary elements of view are captured. See Update Secondary Elements existing in the Repository - Default (DSARIV).
Do Not Merge but use Secondary Element Rules	Existing view definitions remain unchanged. Other preferences determine whether changes to secondary elements of views are captured. See Update Secondary Elements existing in the Repository - Default (DSARIV).
Create a new Element	A new view definition is created with a unique name, i.e. <source object name><number>. Any secondary elements are created on the new view definition.


Update Secondary Elements existing in the Repository -Default (DSARIV)

Related Topics

Default:	No Action Taken
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Views
Use this preference to define the default behavior when updating existing secondary elements of views (relational or object) during database capture. For example, columns associated with relational views.

You can use another preference to override this default for columns.

The options are:

No Action Taken	During database capture, the default behavior is that existing secondary elements of views remain unchanged.
Merge the Secondary Element	Existing secondary element definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing secondary element definitions are deleted from the repository and replaced with new secondary element definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Columns existing in the Repository (COARIV)

Related Topics

Default:	Default Action Taken
Values:	Default Action Taken, No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Views
Use this preference to specify whether existing columns of views can be updated during database capture.

The options are:

No Action Taken	During database capture existing column definitions for views are not updated, they remain unchanged.
Default Action Taken	The behavior is determined by the preference Update Secondary Elements existing in the Repository - Default (DSARIV).
Merge the Secondary Element	Existing column definitions are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing column definitions are deleted from the repository and replaced with new column definitions using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update View Implementations existing in the Repository (VIMAIN)

Related Topics

Default:	Merge the Secondary Element
Values:	No Action Taken, Merge the Secondary Element, Replace Secondary Element
Levels:	Container
Category:	Capture - Views
Use this preference to specify whether existing view implementations can be updated during database capture.

The options are:

No Action Taken	During database capture existing view implementations are not updated, they remain unchanged.
Merge the Secondary Element	Existing view implementations are changed according to the new information coming from the database. Properties that are not captured such as Notes, Description, etc. remain unchanged.
Replace Secondary Element	Existing view implementations are deleted from the repository and replaced with new view implementations using the information coming from the database. Properties that are not captured such as Notes, Description, etc. will be blank.


Update Views existing in the Repository - Warning Level (VAINWL)

Related Topics

Default:	Warning generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Views
Use this preference to specify the type of message displayed during database capture,  when an existing view definition is to be updated.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Update View Implementations existing in the Repository - Warning Level (VIAIWL)

Related Topics

Default:	No Message generated
Values:	No Message generated, Message generated, Warning generated,  Error generated
Levels:	Container
Category:	Capture - Views
Use this preference to specify the type of message displayed during database capture,  when an existing view implementation is to be updated.

The options are:

No Message generated	No message is displayed.
Message generated	An information message is displayed (in black).
Warning generated	A warning message is displayed (in blue).
Error  generated	An error message is displayed (in red). If the "Stop on error" option is checked, the capture process will stop.


Delete Secondary Elements not in the Database - Default (DDESFV)

Related Topics

Default:	No

Values:	Yes, No

Levels:	Container

Category: 	Capture - Views

Use this preference to define the default behavior when deleting secondary elements of views from the repository, during database capture. For example, columns no longer associated with a relational view definition.

You can use another preference to override this default for columns.

The options are:

No	During database capture, the default behavior is not to delete view elements that are no longer in the database.
Yes	The default behavior is to delete view elements that are no longer in the database.


Delete Columns not in the Database - Default (DECOFV)

Related Topics

Default:	Default

Values:	Default, Yes, No

Levels:	Container

Category: 	Capture - Views

Use this preference to specify whether column definitions (of views) can be deleted from the repository during database capture.

The options are:

Yes	During database capture, view columns can be deleted from the repository if they no longer exist in the source database.
No	Columns of views may not be deleted during database capture.
Default	The behavior is determined by the preference DDESFV


Server Generator preferences - organized alphabetically
Server Generator preferences - alphabetical

Related Topics

Select the initial letter of the preference that you require.

A

ADNARP

ADNCKM

ADNCKT

ADNCOM

ADNCOO

ADNCOLT

ADNCOV

ADNEMV

ADNMIM

ADNEOT

ADNEPL

ADNPIM

ADNEWT

ADNTIM

ADNEWV

ADNVIM

ADNFKM

ADNFKT

ADNINM

ADNINT

ADNPKM

ADNPKT

ADNUKM

ADNUKT

ALPHA

ARARIP

B

C

CKARIM

CKARIT

COARIM

COARIO

COARIT

COARIV

D

DEARFP

DECKFM

DECKFT

DECOFM

DECOFO

DECOFT

DECOFV

DADNSM

DADNSP

DADNST

DADNSV

DDESFM

DDESFP

DDESFT

DDESFV

DEFKFM

DEFKFT

DEINFM

DEINFT

DEPKFM

DEPKFT

DEUKFM

DEUKFT

DRPSAC

DSARIM

DSARIP

DSARIT

DSARIV

DTAPIT

E

F

FKARIM

FKARIT

G

GENGRO

GENGUS

GENVFO

H

I

INARIM

INARIT

J

K

L

M

MVAIWL

MVALRI

MVANWL

MIAIWL

MIMAIN

MIANWL

MODINS

N

O

OTAIWL

OTALRI

OTANWL

P

PARSER

PKARIM

PKARIT

PLAIWL

PLALRI

PLANWL

PIAIWL

PIMAIN

PIANWL

Q

QULUSR

R

RECCOM

RECGRT

RECSYN

RRDIFF

RROBJ

RROPT

RRREP

S

T

TAINWL

TALRIN

TANEWL

TIAIWL

TIMAIN

TIANWL

U

UKARIM

UKARIT

USERDM

V

VAINWL

VALRIN

VANEWL

VIAIWL

VIMAIN

VIANWL

W

X Y Z


About Java in the database

Related Topics

Using Oracle Designer to model and generate Java objects

About Java schema objects and Java stored procedures

Using Designer to model Java schema objects

Using Designer to model call specs which publish Java methods

Example - Modeling and generating Java class objects

Example - Modeling and generating Java source objects

Re-generating Java objects

Recording Java objects in the repository

Defining Java source objects

Defining Java class objects

Defining Java resource objects

Recording call specs in the repository

Defining PL/SQL functions/procedures to publish Java methods

Defining packaged PL/SQL functions/procedures to publish Java methods

Defining Oracle object type methods to publish Java methods

Generated Java objects

About generated Java objects

Captured Java  objects

About captured Java objects


About Java schema objects and Java stored procedures

Related Topics

Using Java and Oracle8.1, you can build and deploy powerful server-based Java applications. These applications can easily be distributed across networks, providing access to Oracle data from any computer that supports Java.

Traditional Java development environments

In most Java development environments, Java source code, binaries, and resources are stored as files in a file system. In this case, people tend to refer to source code as .java files and compiled Java (binaries) as .class files. Resources are any data files, such as .properties files, held within the file system hierarchy that are loaded or used at runtime.

When Java is executed a CLASSPATH is specified, which is a set of directories containing your files. Java also provides a way to group these files into a single archive form using  ZIP or JAR files.

Java in Oracle8.1 - About Java schema objects

In Oracle8.1 Java source, Java classes, and Java resources can reside within the database. They are referred to as Java schema objects, of which there are three types: source, class, and resource. Instead of a CLASSPATH, you can use a resolver to specify one or more schemas within which to locate source, class, and resource Java schema objects.

Note:	There are no Java files on the database, i.e. source files (.java), class files (.class), and resource files (e.g. .properties etc.). Instead there are source, class and resource Java schema objects.

•	Java source objects
Source objects contain Java language source code. The code may be either a standard Java compilation unit or a SQLJ compilation unit (which is a Java compilation unit containing static SQL clauses). Oracle8.1 hosts a Java byte-code compiler that compiles Java source to class format when executed.

•	Java class objects
Java class objects contain compiled binary class definitions. Java classes do not need compiling when executed.

•	Java resource objects
Java resource objects contain Java data file content such as .properties files, that are loaded or used at runtime.

You can use Oracle Designer to model these Java objects and to generate CREATE JAVA statements that will load the Java objects into Oracle8.1 databases. About

Java in Oracle8.1 - Loading existing Java files

Oracle8.1 provides a utility for loading existing Java files into the database. The command-line utility (loadjava) uploads Java source, class, and resource files into a system-generated database table (CREATE$JAVA$LOB$TABLE), then uses the SQL CREATE JAVA {SOURCE | CLASS | RESOURCE} statement to load the Java files into the RDBMS. You can upload Java files from file systems, popular Java IDEs, intranets, or the Internet.

Java source code, binaries, and resources can also be loaded directly using CREATE JAVA statements. For example, you can use the CREATE JAVA CLASS statement to load Java class files from local BFILEs and LOB columns.

CREATE JAVA statements which load existing Java files can be generated from the Java source, class and resource definitions you model using Oracle Designer. About

Java in Oracle8.1 - Integrating PL/SQL and Java using stored procedures

Oracle8.1 allows Java objects to be called from server-side PL/SQL. Likewise, PL/SQL objects can be called from server-side Java.

Java stored procedures are Java methods published to SQL and stored in an Oracle database for general use. To publish Java methods, you write call specifications (call specs for short), which map Java method names, parameter types, and return types to their SQL counterparts.

Once published, you can call Java methods from SQL and PL/SQL, through its call spec.

You can use Oracle Designer to model call specs and to generate the DDL necessary to publish Java methods on the database.  About


Using Designer to model Java schema objects

Related Topics

You can use Oracle Designer to model Java schema objects and then generate CREATE JAVA statements that either load Java from local BFILEs and LOB columns, or contain actual Java source code.

Java definitions

All three types of Java object can be modeled in Oracle Designer, i.e. Java class, source and resource objects. They are referred to as Java definitions.

When creating Java definitions you need to specify how the object is to derive Java code. The Java code may be located in a file in an external file system, or within a LOB column on the database. Alternatively, Java source code can be stored within the definition itself (Java source definitions only).

You can also define a resolver clause to specify one or more schemas within which to locate source, class, and resource Java objects.

Logic Editor

Within the Design Editor, a Logic Editor provides a graphical environment for developing Java source code. The editor highlights Java key words and constructs in color.

You can use the Logic Editor to define Java source code for Java source definitions. How

Defining Java objects in the repository

Use the Design Editor to define Java objects in the repository:

Defining Java source objects

Defining Java class objects

Defining Java resource objects


Defining Java source objects

Related Topics

To define a Java source object, create a Java source definition. Optionally, enter Java source code as part of the definition using the Java Block property.

If your source code exists within an external file, or a LOB column on the database, leave the Java Block property empty. Instead, specify the source code location using Java source implementation properties.

Note:	To generate valid CREATE JAVA SOURCE statements, Java implementation details must be defined as described in step 6 below. Subsequently, generation must also take place from the Java source implementation.

To enter a Java source definition and implementation details:

1.	Choose Options→Use Property Dialogs.

2.	Expand the Java Definitions node on the Server Model tab.

3.	Select the Source Definitions node and then choose Edit→Create.

4.	Enter a Short Name and Name for the Java definition and choose Finish.

5.	(Optional) To enter Java source code as part of the definition, do one of the following:

•	Enter Java source code using the Logic Editor:

- Select the new Java source definition on the Navigator.

- Choose Edit Logic from the right mouse button menu.

- Enter the Java source code.

•	Enter Java source code directly into the Java Block property, only accessible via the Property Palette.

6.	From the DB Admin tab, define implementation details:

a	Expand the Oracle Databases and Users nodes and display Schema Objects.

b	Select Java Implementations and then choose Edit→Create.

c	Choose the name of your Java source definition and click Next.

d	If the Java source object is to be based on existing source code, specify the code location. Otherwise continue from step f.

Options are:

•	USING Sub Query - Java source within a CLOB, BLOB, or BFILE column

•	USING External BFILE - Java source within an external BFILE

•	USING Key for LOB column - Java source within a column named LOB in the table CREATE$JAVA$LOB$TABLE

Note: 	If Java source code is defined within the Java definition itself (see step 5), the As Source Text option is selected. Click Next, as none of the other properties apply. Continue from step f.

e	Do one of the following and then choose Next:

•	If in a CLOB, BLOB, or BFILE column, enter the appropriate sub query

•	If in an external BFILE, specify the Directory (must be defined in the repository) and the name of the file

•	If in a column LOB in the table CREATE$JAVA$LOB$TABLE, enter the key for the LOB column, i.e. a value for the column called Name in this table

f	Grant privileges for users and roles and choose Next.

g	Specify the properties Resolve?, Force? and enter a RESOLVER Clause, as required.


Defining Java class objects

Related Topics

To define a compiled Java class in the standard binary class format, create a Java class definition.

Your Java class code may be stored in an external file, or within a LOB column on the database. To define the location of your Java class (.class) you must create a Java class implementation and specify the ‘Create’ properties.

Note:	To generate valid CREATE JAVA CLASS statements, Java implementation details must be defined as described in step 5 below. Subsequently, generation must also take place from the Java class implementation.

To enter a Java class definition and implementation details:

1.	Choose Options→Use Property Dialogs.

2.	Expand the Java Definitions node on the Server Model tab.

3.	Select the Class Definitions node and then choose Edit→Create.

4.	Enter a Short Name and Name for the Java definition and choose Finish.

5.	From the DB Admin tab, define implementation details:

a	Select Java Implementations and then choose Edit→Create.

b	Choose the name of your Java class definition and click Next.

c	Specify how the Java object is to derive class code:

•	USING Sub Query - Java class code within a CLOB, BLOB or BFILE column.

•	USING External BFILE - Java class code within an external BFILE

•	USING Key for LOB column - Java class code within a column named LOB in the table CREATE$JAVA$LOB$TABLE

d	Do one of the following and then click Next.

•	If in a CLOB, BLOB, or BFILE column, enter the appropriate sub query

•	If in an external BFILE, specify the Directory (must be defined in the repository) and the name of the file

•	If in a column LOB in the table CREATE$JAVA$LOB$TABLE, enter the key for the LOB column, i.e. a value for the column called Name in this table

e	Choose Next to grant privileges for users and roles.

f	Choose Next to specify the properties Resolve?, Force? and enter a RESOLVER Clause, as required.


Defining Java resource objects

Related Topics

To define a Java resource in standard portable format, create a Java resource definition.

Your Java resource code may be stored in an external file, or within a LOB column on the database. To define the location of your Java resource (e.g. .properties) you must create a Java resource implementation and specify the ‘Create’ properties.

Note:	To generate valid CREATE JAVA RESOURCE statements, Java implementation details must be defined as described in step 5 below. Subsequently, generation must also take place from the Java resource implementation.

To enter a Java resource definition and implementation details:

1.	Choose Options→Use Property Dialogs.

2.	Expand the Java Definitions node on the Server Model tab.

3.	Select the Resource Definitions node and then choose Edit→Create.

4.	Enter a Short Name and Name for the Java definition and choose Finish.

5.	From the DB Admin tab, define implementation details:

a	Select Java Implementations and then choose Edit→Create.

b	Choose the name of your Java resource definition and click Next.

c	Specify how the Java object is to derive resource code:

•	USING Sub Query - Java resource code within a CLOB, BLOB or BFILE column

•	USING External BFILE - Java resource code within an external BFILE

•	USING Key for LOB column - Java resource code within a column named LOB in the table CREATE$JAVA$LOB$TABLE

d	Do one of the following and then click Next.

•	If in a CLOB, BLOB, or BFILE column, enter the appropriate sub query.

•	If in an external BFILE, specify the Directory (must be defined in the repository) and the name of the file.

•	If in a column LOB in the table CREATE$JAVA$LOB$TABLE, enter the key for the LOB column, i.e. a value for the column called Name in this table.

e	Choose Next to grant privileges for users and roles.

f	Choose Next and enter a RESOLVER Clause, if required.

Note:	Properties Resolve? and Force? do not apply to Java resource objects.


Using Designer to model call specs which publish Java methods

Related Topics

Java stored procedures are Java methods published to SQL and stored in an Oracle database for general use. In order to publish Java methods so that they can be called from SQL, you need to define a call spec. Call specs map Java method names, parameter types, and return types to their SQL counterparts.

A call spec and the Java method it publishes must reside in the same schema. On the database (and in Designer), call specs can be defined in the following ways:

•	stand-alone (top-level) PL/SQL function or procedure How

•	packaged PL/SQL function or procedure  How

•	member method of an Oracle object type  How

A call spec exposes a Java method’s top-level entry point to Oracle. So, you can publish only public static methods, with one exception. You can publish instance methods as member methods of an Oracle object type.

Packaged call specs perform as well as top-level call specs. So, to ease maintenance, you might want to place call specs in a package body. That way, you can modify them without invalidating other schema objects. Also, you can overload them.

Datatype mapping

In a call spec, corresponding SQL and Java parameters (and function results) must have compatible datatypes. Oracle maintains a list of legal datatype mappings and converts between the SQL types and Java classes automatically.

SQL Type	Java Class
CHAR, NCHAR, LONG, VARCHAR2, NVARCHAR2	oracle.sql.CHAR java.lang.String java.sql.Date java.sql.Time java.sql.Timestamp java.lang.Byte java.lang.Short java.lang.Integer java.lang.Long java.lang.Float java.lang.Double java.math.BigDecimal byte, short, int, long, float, double
DATE	oracle.sql.DATE java.sql.Date java.sql.Time java.sql.Timestamp java.lang.String
NUMBER	oracle.sql.NUMBER java.lang.Byte java.lang.Short java.lang.Integer java.lang.Long java.lang.Float java.lang.Double java.math.BigDecimal byte, short, int, long, float, double
RAW, LONG RAW	oracle.sql.RAW byte[ ]
ROWID	oracle.sql.CHAR oracle.sql.ROWID java.lang.String
BFILE	oracle.sql.BFILE
BLOB	oracle.sql.BLOB oracle.jdbc2.Blob
CLOB, NCLOB	oracle.sql.CLOB oracle.jdbc2.Clob
OBJECT	oracle.sql.STRUCT oracle.SqljData oracle.jdbc2.Struct
REF	oracle.sql.REF oracle.jdbc2.Ref
TABLE, VARRAY	oracle.sql.ARRAY oracle.jdbc2.Array
Any of the above SQL types	oracle.sql.CustomDatum oracle.sql.Datum


Defining PL/SQL functions/procedures to publish Java methods

Related Topics

You can define a ‘top-level’ call spec that publishes a Java method, via a PL/SQL function or procedure.

Note:	You can define a call spec that publishes one or more related Java methods, via a PL/SQL package. How

To define a ‘top-level’ call spec:

1.	Choose Options→Use Property Dialogs.

2.	Expand the PL/SQL Definitions node on the Server Model tab.

3.	Select the Function or Procedure node and then choose Edit→Create.

4.	Enter a Short name and Name for the PL/SQL definition.

This does not need to match the Name of the Java method.

5	Click Next and specify that the PL/SQL definition is to be Declarative.

6.	For functions only. Choose the Return datatype and then click Next

This return datatype must match that of the Java method.

7.	For each Java parameter, enter the corresponding argument:

a	Enter the name of the argument. The name must match that used in the Java method.

b	Choose the datatype that matches the Java parameter.  About

c	Specify the Argument Type, if appropriate.

The Maximum Length and Default Value properties do not apply.

8.	Click Next three times to display the Java tab.

The Exception and Program Data tabs can be ignored as this information is not applicable to call specs.

9.	Choose the Name of the Java definition in which the Java method is defined.

During generation the Implementation Name of the selected Java definition is used within the call spec to identify the Java method. If you have not done so already, ensure that the Implementation Name is defined.

Note:	If this property is left blank, ensure that the Java method property fully qualifies the method, i.e. specifies the Java schema object.

10.	Enter the exact name of the Java method this call spec is to publish.

11.	List the parameters of the Java method, separating each one with a comma.

Parameters are mapped to arguments by position and must correspond one to one.

12.	Enter the Return Type, if one is defined in the Java method.

13.	Choose Finish.


Defining packaged PL/SQL functions/procedures to publish Java methods

Related Topics

You can define a call spec that publishes one or more related Java methods, via a PL/SQL package.

To define a packaged call spec:

1.	Define a ‘top-level’ call spec for each Java method to be included in the package. How

If other objects are to access the procedures/functions, define the Scope as Public.

2.	Create and name the PL/SQL package:

a	Choose Options→Use Property Dialogs.

b	Expand the PL/SQL Definitions node on the Server Model tab.

c	Select the Package Definitions node and then choose Edit→Create.

d	Enter a Short name and Name for the PL/SQL definition and click Next.

e	Specify that the PL/SQL definition is to be Declarative and click Finish.

3.	Define the structure of the declarative PL/SQL package:

a	Expand the PL/SQL Composition node on the Server Model tab.

b	Select the declarative package created in step 2.

c	Choose Sub Program Units from the right mouse menu.

d	Choose the PL/SQL definition(s) you want to include within the selected package, i.e. the Java method call specs defined in step 1.

e	Repeat steps c and d until the structure of your declarative package is complete.


Defining Oracle object type methods to publish Java methods

Related Topics

You can define a call spec that publishes one or more related Java methods, via an Oracle object type.

Functions and procedures that characterize the behavior of the Oracle object type are called methods. These methods can define call specs to Java methods.

To define a Oracle object type call spec:

1.	Choose Options→Use Property Dialogs.

2.	Define an Oracle object type with at least one attribute. How

3.	Define a Java method call spec via an Oracle object type method:

a	On the Navigator, expand the Oracle object type created in step 2.

b	Choose the Methods node and select Create Method from the right mouse menu.

c	Enter a Short name and Name for the PL/SQL definition.

This does not need to match the Name of the Java method.

d	Click Next and specify whether the call spec is for a procedure or a function

e	Specify that the procedure or function is to be Declarative.

f	For functions only. Choose the Return datatype and then click Next

The selected datatype must match that of the Java method.

g	For each Java parameter, enter the corresponding argument:

-	Enter the name of the argument. The name must match that used in the Java method.

-	Choose the datatype that matches the Java parameter. About

-	Specify the Argument Type, if appropriate.

The Maximum Length and Default Value properties do not apply.

h	Click Next three times to display the Java tab.

The Exception and Program Data tabs can be ignored as this information is not applicable when defining a call spec.

i	Choose the Java definition in which the Java method is defined.

Note:	If this property is left blank, ensure that the Java method property fully qualifies the method, i.e. specifies the Java schema object.

j	Enter the exact name of the Java method this call spec is to publish.

k	List the parameters of the Java method, separating each one with a comma.

Parameters are mapped to arguments by position and must correspond one to one.

l	Enter the Return Type, if one is defined in the Java method.

m	Choose Finish.


Example - Modeling and generating Java class objects

Related Topics

This example illustrates how you can use Oracle Designer to model a Java class object that loads the Java class file GenericDrop.Class onto a database. The example also illustrates how to model a call spec to publish it's Java method dropIt as a stored procedure, for general use in an Oracle8.1 database.

Follow these steps:

		Create the Java class file using  favourite Java IDE  Use Oracle Designer to model  the Java class  Generate CREATE JAVA statement and load Java class onto a database  Use Oracle Designer to model a call spec which publishes the Java method  Generate CREATE PROCEDURE statement and publish the Java method   Call the stored procedure (Java method) from SQL or PL/SQL
1.	Create Java files (source, class, resource) using favorite Java IDE.

For this example, create the Java class GenericDrop with one method named dropIt, which drops any kind of database object. For example, if you pass the arguments ’table’ and ’emp’ to dropIt, the method drops database table emp from your schema:

public class GenericDrop {

public static void dropIt (String object_type, String object_name)

throws SQLException {

// Connect to Oracle using JDBC driver

Connection conn = new OracleDriver().defaultConnection();

// Build SQL statement

String sql = "DROP " + object_type + " " + object_name;

try {

Statement stmt = conn.createStatement();

stmt.executeUpdate(sql);

stmt.close();

} catch (SQLException e) {System.err.println(e.getMessage());}

}

}

Compile the Java class and store the file GenericDrop.class in a directory that is accessible from your database. For example d:\My_Java

2.	Use Oracle Designer to model the Java class.

For this example, in the Design Editor:

•	Choose Options→Use Property Dialogs

•	Create a directory definition which maps to d:\My_Java  How

•	Create a Java class definition named ‘GenericDrop’ and then create a Java class implementation that specifies that the class is to be created from ‘an external BFILE’. Choose the directory and enter the class file name, i.e. GenericDrop.class How

3.	Generate the CREATE JAVA statement and load the Java class onto the database.

In the Design Editor:

•	Generate DDL from the directory definition and Java class implementation and run the script on an appropriate Oracle8.1 database  How

The generated CREATE JAVA statement loads the Java class onto the database.

4.	Use Oracle Designer to model the call spec required to publish the Java method as a stored procedure.

In the Design Editor:

•	Choose Options→Use Property Dialogs

•	Create a PL/SQL procedure definition named ‘Call_Drop_It’  How

•	Enter two arguments ‘object_type’ and ‘object_name’, both with the datatype ‘VARCHAR2’

•	On the Java tab choose the Java definition named ‘GenericDrop’, enter ‘dropIt’ for the Java method name and enter the parameter list as java.lang.String, java.lang.String

Notice that you must fully qualify the reference to class String. The package java.lang is automatically available to Java programs but must be named explicitly in call specs.

5.	Generate the CREATE PROCEDURE statement and publish the Java method on the database.

In the Design Editor:

•	Generate DDL from the PL/SQL procedure definition and run the script on the same Oracle8.1 database. How

The generated CREATE PROCEDURE statement publishes the Java method as a stored procedure on the database.

6.	Call the Java stored procedure from SQL or PL/SQL.

For example, call the Java method dropIt within SQL or PL/SQL defined in the repository, i.e:

−	PL/SQL definitions, i.e. any PL/SQL block, subprogram, or package

−	Database trigger definitions


Example - Modeling and generating Java source objects

Related Topics

This example illustrates how you can use Oracle Designer to model a Java source object named Hello that contains Java source code as part of its definition. The example also illustrates how to model a call spec to publish the Java method World as a stored procedure, for general use in an Oracle8.1 database.

Note:	Oracle8.1 hosts a Java byte-code compiler that compiles Java source code to class format when CREATE JAVA SOURCE statements are executed.

Follow these steps:

		Use Oracle Designer to model Java source object and enter source code  Generate CREATE JAVA SOURCE statement  Use Oracle Designer to model a call spec to publish the Java method  Generate CREATE FUNCTION statement and publish the Java method   Call the stored procedure (Java method) from SQL or PL/SQL
1.	Use Oracle Designer to model the Java source and enter Java source code.

For this example, in the Design Editor:

•	Choose Options→Use Property Dialogs

•	Create a Java source definition named ‘Hello’ and then use the Logic Editor to enter Java source code. How   (Ignore step 6)

Enter the Java source code that defines the class Hello  that has one method Hello.world that returns the string “Hello world”, i.e.

public class Hello {

public static String world() {

return "Hello world"; } };

2.	Generate the CREATE JAVA SOURCE statement and load the Java source onto the database.

In the Design Editor:

•	Generate DDL from the Java source definition and run the script on an appropriate Oracle8.1 database  How

The generated CREATE JAVA SOURCE statement loads the Java source onto the database and compiles Java source code to class format.

3.	Use Oracle Designer to model the call spec required to publish the Java method as a stored procedure.

In the Design Editor:

•	Choose Options→Use Property Dialogs

•	Create a PL/SQL function definition named ‘HELLOWORLD’  How

•	Specify the function Return Datatype as VARCHAR2

•	On the Java tab choose the Java source definition named ‘Hello’, enter ‘world’ for the Java method name, and specify the Java Return Type as java.lang.String.

Notice that you must fully qualify the reference to class String. The package java.lang is automatically available to Java programs but must be named explicitly in call specs.

4.	Generate the CREATE FUNCTION statement and publish the Java method on the database.

In the Design Editor:

•	Generate DDL from the PL/SQL function definition and run the script on the same Oracle8.1 database. How

The generated CREATE FUNCTION statement publishes the Java method as a stored procedure on the database.

5.	Call the Java stored procedure from SQL or PL/SQL.

For example, call the Java method World within SQL or PL/SQL you define in the repository, i.e:

−	PL/SQL definitions, i.e. any PL/SQL block, subprogram, or package

−	Database trigger definitions


Re-generating Java objects

Related Topics

If you re-generate existing Java objects directly to an Oracle database Server Generator does not attempt to  reconcile the differences. DDL is always generated to create or replace Java object on the database.

However, the reconcile report will show whether or not a Java object exists with the same name.


About advanced queuing (AQ)

Related Topics

Using Designer to model and generate AQ objects

AQ Example - Generating a persistent queue for one consumer (single database user)

AQ Example - Generating a multi-consumer queue (multiple database users)

Re-generating advanced queuing (AQ) objects

Defining AQ objects in the repository

Defining queue tables

Defining queue table implementations

Defining persistent queues

Defining persistent queue implementations

Defining queue subscribers

Defining non-persistent queues

Defining non-persistent queue implementations

Generated AQ objects

About generated queue tables/queue table implementations

About generated persistent queues/persistent queue implementations

About generated non-persistent queues/non persistent queue implementations

About generated queue subscribers

Captured AQ objects

About captured queue tables/queue table implementations

About captured persistent queues/persistent queue implementations

About captured non-persistent queues/non-persistent queue implementations

About captured queue subscribers


AQ Example - Generating a persistent queue for one consumer (single database user)

Related Topics

Persistent queues are stored in queue tables.  Each queue table can contain one or more queues.  This example  illustrates a single consumer queue, i.e. a queue that contains messages that are to be dequeued and processed by one consumer only. Note that queue subscribers are not required for single consumer queues.

To model and then generate DDL for these AQ objects, follow the steps below:

	Define the queue table  Define the persistent queue (single consumer)  Generate DDL for the queue table and the queue (Server Model tab)
For a more complex advanced queuing example, see Generating a multi-consumer queue (multiple database users)


AQ Example - Generating a multi-consumer queue (multiple database users)

Related Topics

To specify user-specific storage information for a queue table, define a queue table implementation. Queue table implementations are defined in the context of a database user definition.

To define queue subscribers for multi-consumer queues, or to grant (or revoke) queue privileges, define a persistent queue implementation.  Queue implementations are defined in the context of a database, rather than a database user definition.

Note:	On the database, the queue table and the queue are always owned by the same user.

To model and then generate DDL for these AQ objects, follow the steps below:

	Define the queue table  Define queue table implementation details  Define the persistent queue (multi-consumer) Define persistent queue implementation detail: - Grant queue privileges to user/role  - Grant AQ system privileges to user/role  Define queue subscribers  Set ‘User Qualified Name’ preference  Generate DDL for queue table, queue, subscribers etc. with implementation details (DB Admin tab)

For a less complex advanced queuing example, see AQ Example - Generating a persistent queue for one consumer (single database user)


Re-generating advanced queuing (AQ) objects

Related Topics

If you re-generate existing AQ objects directly to an Oracle database Server Generator will attempt to reconcile the differences. The following tables show which properties can be reconciled and which API calls will be generated.

Note:	Subscriber cannot be re-generated alone, and have always to be regenerated with their queues.

Queue tables - DBMS_AQADM.ALTER_QUEUE_TABLE

Queue Table Name	Cannot be updated but is used to reference the table
Comment	Does not need to be generated if no change.
Primary Instance	Does not need to be generated if no change.
Secondary Instance	Does not need to be generated if no change.
Persistent queues - DBMS_AQADM.ALTER_QUEUE

Queue Name	Cannot be updated but is used to reference the persistent queue.
Max Retries	Does not need to be generated if no change.
Retry Delay	Does not need to be generated if no change.
Retention Time/ Unlimited Retention Time ?	Does not need to be generated if no change.
Auto Commit	Always specified, even if unchanged as default is TRUE.
Comment	Does not need to be generated if no change.
Non-persistent queue

No values can be updated. A non-persistent queue is only created if it does not exist in the database.

Subscriber - DBMS_AQADM.ALTER_SUBSCRIBER

The only property which can be changed is the Rule.

System privileges

Cannot be reconciled.

Queue privileges

Cannot be reconciled.


Defining queue tables

Related Topics

You can define a queue table for storing one or more persistent queues in the repository.  About

To define a queue table:

1.	Choose Options→Use Property Dialogs.

2.	Select the Queue Table Definitions node on the Server Model tab.

3.	Choose Edit→Create.

4.	Enter a Name for the queue table that is 24 characters or less.

5.	Define whether the table is based on a Oracle Object Type, or a Scalar Type.

6.	Specify whether the table is to store single consumer queues, or multiple consumer queues.

7.	Specify additional information on the other pages as required, for example:

•	how queue messages are committed

•	how queue messages are grouped

•	how the queue messages are sorted (priority or enqueue time), etc.


Defining queue table implementations

Related Topics

You can define a queue table implementation to record how a queue table will be implemented on a database for a particular user.  About

To define a queue table implementation:

1.	If you have not done so already:

•	Define the base queue table  How

•	Define the Oracle database  How

•	Define the user with which the queue table is to be associated  How

2.	Choose Options→ Use Property Dialogs

3.	On the Navigator, select the DB Admin tab.

4.	Expand the Oracle Databases and Users nodes to show Schema Objects.

5. 	Select Queue Table Implementations and choose Edit→Create.

6. 	Choose the queue table definition that you want to tailor for this user and then choose Next.

7.	Specify additional information on the other pages as required, for example:

•	Tablespace in which table implementation will be created

•	Storage details

•	Data blocks (Percent Free/Percent Used)

•	A database user for the Oracle object type (only if queue table based on an object type)

8.	To specify that the name of this table implementation is to be prefixed with the name of its associated database user during generation, set the preference Use User Qualified Names for Advanced Queuing Objects (QULUSR) to Yes. How

Note:	If the queue table is based on an Oracle object type and QULUSR is set to Yes, the name of the Oracle object type is also prefixed with its associated database user name.

As persistent queues are always created in the same database user as their queue table, setting the QULUSR preference indirectly allows you to specify the database user for queues.


Defining persistent queues

Related Topics

You can define a persistent queue in the repository.  About

To define a persistent queue:

1.	Choose Options→Use Property Dialogs.

2.	Select the Queue Definitions node on the Server Model tab, then Persistent Queues.

3.	Choose Edit→Create.

4.	Enter a Name for the queue that is 24 characters or less.

5.	Specify the Queue Type, i.e. whether this is a normal queue, or an exception queue.

6.	Choose the Queue Table where this queue is to be stored.

7.	Specify additional information on other pages as required, for example:

•	how queue messages are committed

•	the number of times messages can be dequeued (removed)

•	the length of time messages are retained, etc.

Next step

Define implementation details. How


Defining persistent queue implementations

Related Topics

You can define a persistent queue implementation in the repository to record how it is to be implemented on a database.  About

In Designer, persistent queue implementations are defined in the context of a database rather than a database user. As queue tables and queues are always owned by the same user, the Queue Table Database User property indirectly specifies the target database user.

To define a persistent queue implementation:

1.	If you have not done so already:

•	Define the base queue table  How

•	Define the Oracle database  How

2.	Choose Options→ Use Property Dialogs

3.	On the Navigator, select the DB Admin tab.

4.	Expand the required Oracle Databases node.

5.	Select Queue Implementations, then Persistent Queue Implementations.

6.	Choose Edit→Create.

7.	Choose the persistent queue definition that you require and then choose Next.

8.	Specify additional information on the other pages as required, for example:

•	how queue messages are committed

•	the number of times messages can be dequeued (removed)

•	the length of time messages are retained

•	a database user for the associated queue table (and this queue)

•	queue privileges for users and roles, etc.

Next step

If this is a multi-consumer queue you can define one or more queue subscribers. How

You can also grant AQ system privileges to user or role definitions. How


Defining queue subscribers

Related Topics

You can define one or more queue subscribers for persistent and non-persistent queues defined in the repository.  About

To define a queue subscriber:

1. 	If you have not done so already, define a queue implementation:

•	persistent queue implementation How

•	non-persistent queue implementation How

Note:	Subscribers are only applicable for multi-consumer queues. They can not be defined for exception queues or single consumer queues. For persistent queues, the Multiple Consumer? property of its associated queue table must be set to Yes. For non-persistent queues, set the Multiple Consumer? property to Yes.

2.	Choose Options→ Use Property Dialogs

3.	On the Navigator, select the DB Admin tab.

4.	Expand the required Oracle Databases node.

5.	Select Queue Implementations, then expand the required implementation definition.

6.	Select Queue Subscribers and choose Edit→Create.

7.	Specify a Name and Address for the subscriber and then choose Next.

8.	For persistent queues only, enter a Rule for the subscriber if required.


Defining non-persistent queues

Related Topics

You can define non-persistent queues in the repository.  About

To define a non-persistent queue:

1.	Choose Options→Use Property Dialogs.

2.	Select the Queue Definitions node on the Server Model tab, then Non-Persistent Queues.

3.	Choose Edit→Create.

4.	Enter a Name for the queue that is 24 characters or less.

5.	Specify whether the queue is to be used by a single consumer, or multiple consumers.

Next step

Define implementation details. How


Defining non-persistent queue implementations

Related Topics

You can define a non-persistent queue implementation in the repository to record how it is to be implemented on a database and grant queue privileges for users and roles.  About

In Designer, non-persistent queue implementations are defined in the context of a database rather than a database user.

To define a non-persistent queue implementation:

1.	If you have not done so already, define the Oracle database.  How

2.	Choose Options→ Use Property Dialogs

3.	On the Navigator, select the DB Admin tab.

4.	Expand the required Oracle Databases node.

5.	Select Queue Implementations, then Non-Persistent Queue Implementations.

6.	Choose Edit→Create.

7.	Choose the non-persistent queue definition that you require and then choose Next.

8.	Specify queue privileges for users and roles as required.

Next step

If this is a multi-consumer queue you can define one or more queue subscribers. How

You can also grant AQ system privileges to user or role definitions. How


Refining a captured database design

After you have captured definitions of tables, constraints and other database objects, you can examine the definitions in the repository and refine the design ready for implementation.

Tip:  Create a Server Model Diagram to work with the design graphically.

How

Migrating the design to another target database	If you plan to generate database objects on a target database different from the original database, check that the names of objects in the same namespace are unique. For example, a table called EMP cannot be created on the same database as a view called EMP. Database objects whose names duplicate the name of another object of the same type can be renamed.
Examine datatype mappings	When you capture column definitions, the datatype is mapped onto a repository datatype.  About  You can examine the datatypes of captured columns to ensure that the design meets your requirements.
Denormalized columns	In some circumstances, you may want to introduce some controlled redundancy into your table design in order to improve performance. This is sometimes referred to as denormalizing the design.  About
Synonyms	A public synonym is owned by the special user group named PUBLIC and every user in a database can access it. A private synonym is contained in the schema of a specific user who has control over its availability to others.
Next step?

(Optional)  Enhance the database design


Setting up the repository

Create a workarea

You create and work with repository objects within the context of a workarea. Database objects created within a workarea can be generated to a single user account on a database, or written to a DDL script file.

Create a database definition  How

You should create a database definition:

•	before capturing objects from an existing database. Objects are always captured for a specific user within a specific database

•	to generate a new physical database

•	to design a distributed system

Create a user definition  How

The database user you create will have access to the database within which it is defined. The Server Generator can use these definitions to generate GRANT statements. These GRANT statements may be run by an administrator, using Oracle SQL*PLUS or SQL*DBA, to enroll new users.


Quick steps to database design

You can quickly create a set of tables, columns and constraints with many defaults provided for you.

The following defaults are provided:

•	column datatype VARCHAR2(240))

•	primary key column <table_name>_ID (mandatory, datatype NUMBER, non-updateable)

•	foreign key column to match the primary key column

To quickly create a default database design:

1.	In the Navigator, select the Server Model tab in the Navigator.

2.	In the Navigator, select the Relational Tables node.

3.	Choose Edit→Fast Create.

4.	Enter the names of all tables you want to create.

5.	Drag the table definitions onto the work area to display them on a Server Model Diagram.

6.	Define at least one column for each table.

−	Select a table on the diagram

−	Select the column toolbar button

−	Enter the names of all columns you want to create

7.	Define a primary key for each table.

−	Select the primary key toolbar button

−	Click on a table on the diagram

A default primary key column is created for you.

8.	(Optional)  Edit table and column definitions. You may want to add a column to the primary key, rename the primary key column or change the column datatype.

9.	Define foreign keys to join related columns together.

−	Select the foreign key (Mandatory or Optional) toolbar button.

−	Click on the table for which the foreign key is to be defined

−	Click on the table containing the primary key to be referenced

10.	(Optional)  Create an index on the primary key or foreign key.

Next step?

Generate the database design


Planning the database structure

Before you start recording the database design in the repository, you will need to make some design decisions as to the content and structure of your design. Consider the following design issues.

General design principles

Tables and column definitions	Decide what tables and columns you need. You should create a table definition for each type of data to be stored in the database, and define at least one column for each table.  About
Domains for common data items	Are there any common items of data that can be defined as domains? Domains provide an efficient way of defining common items of data, by allowing you to define properties that are shared by many columns only once.  About
Allowable values for columns	Do any of the column have default values, or can allowable values or a range of values be specified?  About
Data integrity	What types of integrity constraint should be defined? Each table definition should have a primary key to ensure that the table cannot contain duplicate data. Uniqueness can also be enforced on optional columns (NULL) by defining unique keys. Related columns can be joined and queries simplified by defining foreign key constraints to preserve referential integrity. You will also need to decide where constraints should be enforced; on the server, on both server and client, or on the client only.
Naming conventions	Consider that the names of repository objects cannot exceed 30 characters. Also, that database objects with reserved names, e.g. SYSDATE cannot be stored in the repository.
Storage requirements	What are the physical storage requirements for the database objects? You can define different storage parameters for a given object. This allows you to generate the object on different databases with different storage parameters.  About
Database administration	Do you need to create a database instance, with rollback segments, users, and roles?
Performance considerations	Can the performance of queries on the database be improved by defining indexes on foreign keys, or by joining frequently queried tables using views? Can common column be clustered together to improve access to those columns, or do you need to denormalize columns to speed up queries on the underlying tables?
Security	What security restrictions should be enforced? Do you need synonyms to mask the location of a table, or views to restrict user access to sensitive data in a table?  What privileges should be granted to users and roles?  About
Oracle-specific designs

When designing for an Oracle database, you may also want to consider some additional design issues:

Auditing information	Do the tables require journaling information? You can generate a journal table to keep records of the rows inserted, updated and deleted in a table. How  Auditing information can also be recorded for columns.
Auto-generated column values	Can any column values be generated automatically, to minimize errors when data is inserted or updated in the column? The following types of value can be generated automatically: • unique and sequential values for numeric columns, often the primary key of the table  • default values in the event of a value being omitted  • auditing information about the column
Additional data integrity	Do you need to enforce additional data integrity constraints using database triggers?
Data distribution	Will the design be distributed across different databases? You can design materialized views of a table that is to be implemented on a remote and local site. Database objects created on a master site can also be replicated automatically on remote sites.
Oracle8 database	Do you need to define index-only tables, or partition table, views and indexes?


approaches to creating tables
Creating table definitions

There are different ways you can create table definitions in the repository:

•	by transforming entity definitions

•	by capturing tables from a database catalog or script  How

•	by entering new definitions in the repository

Tip: 	If you are new to Oracle Designer, you can use the Server Model Guide to help you create table definitions and other database objects.

To create table definitions:

•	Use the Fast Create option from the Edit menu to create multiple table definitions in one step. This option provides a fast and convenient way of creating more than one table, using default settings. You can change these defaults later.

or

•	Use the Create option from the Edit menu to create a single table definition in more detail. This option allows you to define a more detailed table definition with columns, primary key and foreign key constraints.

To create a single table definition (detailed option):

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	In the Navigator, select the Server Model view.

3.	Select the Table Definitions node.

4	Choose Edit→Create.

5.	Define at least the following properties. Browse through the dialog to define each one.

−	Table Name

−	Column Name

−	Datatype

−	Length (maximum, if applicable to the Datatype)

−	Optionality

Columns are optional by default. If the column is mandatory, set the optionality to No.

−	Primary key (recommended)

You can continue working with these designs in the Navigator or, if you prefer to work with the design graphically, select the table definitions and drag them onto the work area. This displays your design in a Server Model Diagram. You can create additional table definitions on the diagram. How

Next step?

•	If you created multiple tables (basic definitions only), you will need to define columns. How

•	If you created a more detailed table definition, you may want to edit the table and column properties. How


Defining columns

A column defines the characteristics of the data to be stored in a table. When you define a column, you must determine the following:

•	choose an appropriate datatype  About

•	define the maximum length of data the column can hold

•	decide whether a value should always be provided for the column. If so, use the detailed option to define the column as mandatory (Optional = No).

•	decide on the order in which columns are to be created on the table. By default, columns are created in alphabetical order.

•	determine whether the column has properties in common with other items of data. If so, you can define a domain so that the definition can be reused. How

These tasks tell you how to define:

•	multiple columns for a table in a single step. Columns created in this way have the default datatype Varchar2 (240) and are optional (NULL). Later, you can change these defaults.

•	one or more columns in detail. This allows you to specify the datatype, optionality and define allowable values for the column.

You should define at least one column for each table.

To define multiple column definitions with default properties (Fast Create option):

1.	In the Navigator, select the Server Model view.

2.	Expand the relational table node for which columns are to be defined.

3.	Select the Columns node.

4.	Choose Edit→Fast Create.

5.	Click the cursor in the Name field and enter a unique name for each column definition you want to create.

To define one or more column definitions in detail (detailed option)

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	Do one of the following:

−	If you have a Server Model Diagram open with the table displayed, double-click on the table.

Or

−	In the Navigator, double click the table node.

3.	Select the Columns tab.

4.	Define at least the following column properties:

−	Column name

−	Datatype

−	Length (maximum, if applicable to the Datatype)

−	Optionality

Columns are optional by default, but you can set the optionality to No (mandatory) if a value must always be provided for the column.

5.	(Optional)  You can also define any of the following:

−	a domain from the column

−	a default value for the column

−	allowable values, such as a list of discrete values or range of values

Note:	Do this only if the column is not included in a domain. Allowable values defined against the column will override those defined at domain-level.

−	advanced properties, such as the Default Value Type etc.

6. 	Select Finish.

Next step?

Edit table and column definitions

Defining allowable values


Editing table and column definitions

When you create table and column definitions, defaults are provided for properties that you did not explicitly specify. Before proceeding with the design, you may want to edit the properties that will be used during generation to ensure they meet your design requirements. How

Specifically, if you did not specify the datatype and optionality for a column, the following defaults are provided.

Column defaults

•	column datatype set to VARCHAR2  About

•	maximum length set to 240

•	column optionality set to Optional (NULLs allowed)

You can edit the column to:

•	change column details

•	rename columns in the primary key

•	change the datatype, and/or maximum length of the primary key column

Primary key column defaults

•	column datatype set to NUMBER

•	column optionality set to Mandatory (NOT NULL)

You can edit the primary key to:

•	add columns to the primary key

•	remove columns from the primary key

•	change the validation criteria

•	specify constraint error messages and exceptions tables

To edit table and column definitions:

1.	In the Navigator, choose Options→Use Property Dialog

2.	In the Navigator, double-click a relational table node.

3.	Change table definition properties as required using the following tabs:

−	Name tab

−	Advanced tab

4.	Select the Columns tab.

5.	Select each column in turn and examine the following column properties.

If necessary, specify an alternative value:

Name	Primary key columns (table_name_ID) and foreign key columns (pkey_column_<number>) are assigned default names that you can rename as required.
Datatype	Column Default = VARCHAR2 Primary key column default = NUMBER Ensure that the datatype is appropriate for the type of data to be stored in the column.  About
Maximum Length	Default = 240 The default is the maximum permitted length. You may want to decrease this length but should ensure that it is long enough to hold the longest item of data, as the length cannot be increased when the table contains data.
Optional?	Default = Yes Allows NULL values to be stored in the column. If the column should not contain NULLs (i.e. it is mandatory), set this property to No.
6.	Save the changes.

Next step?

Define integrity constraints


Creating domains

During design, you may identify groups of columns that share a common set of properties. Domains provide a convenient way of defining columns whose values do not change over time, such as Yes/No values, days of the week and currency values. For any common item of data, you should create a domain definition.

You can create a domain:

•	from an existing column definition

•	by entering a new domain definition. You can create:

−	multiple domain definitions, that have the default datatype Varchar2

−	a single domain definition in detail. This option allows you to specify the datatype, optionality and provide valid values for the domain.

After you create the domain, you can associate it with any column that shares the domain properties.

To create a domain from an existing column definition:

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	Do one of the following:

−	If you have a Server Model Diagram open with the table displayed, double-click on the table.

Or

−	In the Navigator, double click the relational table node

3.	Select the Column tab.

4.	Select the column from which the domain is to be created.

5.	Enter a new Domain name in the domain field.

6.	Select Finish.

To define a domain definition in detail:

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	In the Navigator, select the Server Model tab.

3.	Select the Domains node.

4.	Choose Edit→Create

5.	Define at least the following domain properties:

−	Domain name

−	Datatype  About

−	Length (maximum, if applicable to the Datatype)

6.	(Optional)  You can also define a default value or allowable values for the domain, such as a list of values or range of values  About

Note:	As an intended format mask cannot be determined prior to generation, the only correct way of defining a date value (default value or allowable value) is to specify the format mask. For example, enter the value TO_DATE('01-01-2000', 'DD-MM-YYYY').

7.	Select Finish.

To associate a column with a domain:

1.	Double-click the column to be included in a domain.

2.	Set the column Domain property to the name of the domain.


Creating exceptions tables

An exceptions table is a database table used specifically to store constraint violations. You must generate the exceptions table in the same schema as the tables that will use the exceptions table. You can create an exceptions table specifically for this purpose or you can use an existing table.

To create an exceptions table:

•	Create a relational table definition to be used for constraint exceptions. How

Tip:  	Use a suitable naming convention, for example <constraint_type>EXCEPTION, up to a maximum of 30 characters.

Associate constraints with the exceptions table:

1.	Double click the constraint that will use the exceptions table.

2.	From the Exceptions table drop-down list, select the name of the exceptions table.

3.	Save the changes.


About allowable values

Related Topics

If a column will always hold a particular value or type of value, you can define the allowable values as a business constraint against the column or associated domain, to prevent invalid data being recorded in the table. Values that are frequently used by more than one column should be defined against a domain.

The type of valid value constraint that can be defined for a column must be compatible with the column datatype.

Valid value constraints	Column datatype
Define default column values	Character, Numeric, Date
Define allowable values	Character
Define uppercase only values	Character
Using sequences to generate unique values for numeric columns	Numeric
Define a range of values for numeric columns	Numeric


Defining allowable values

Related Topics

When you define a column or a domain, you can specify allowable values that the column can hold, to restrict the data that can be recorded in the column. Allowable values can be defined if the column has a character datatype (for example Char, Varchar, Varchar2).

When you define allowable values, you must specify what type of validation code is to be generated. By default, allowable values are enforced using generated valid value constraints.  About

To define allowable values against a column:

1.	In the Navigator, select the column for which allowable values are to be defined.

2.	Select the Allowable Values node.

3.	Select the Create button.

4.	In the Value field, enter a value that is allowed for the column.

5.	(Optional)  Enter an abbreviation and meaning.

6.	Repeat steps 4 and 5 for each additional value.

7.	(Optional)  By default, the values will be displayed in alphabetical order. You can change the order by changing the values of the Display Sequence.

8.	Select the column instance and specify the type of validation required, using the table below to determine the column settings:

Validate in Server only (Default option)	Validate in Server and Client
Dynamic List?= No	Dynamic List?= Yes
To define allowable values against a domain:

1.	In the Navigator, select the domain for which allowable values are to be defined.

2.	Select the Allowable Values node.

3.	Select the Create button.

4.	In the domain Value field, enter a valid value.

5.	(Optional)  Enter an abbreviation and meaning.

6.	Repeat steps 4 and 5 for each additional value.

7.	(Optional)  By default, the values will be displayed in alphabetical order. You can change the order by changing the values of the Display Sequence.

8.	Associate columns with the domain.

−	Select the column that is in the domain.

−	In the Column property window, select the domain name from the Domain field.

9.	Specify the type of validation required, using the table below to determine the column settings:

Validate in Server only, (Default option)	Validate in Server API and Client
Dynamic List?= No	Dynamic List?= Yes


Defining a range of values for numeric columns

Related Topics

When you define a numeric column, you can specify a range of values that the column can contain. Value ranges that apply to more than one column should be defined against a domain.

By default, the Server Generator generates a check constraint against the column to enforce the value range on the database.  About

To define a range of values against a column:

1.	In the Navigator, select the column for which a range of values is to be defined.

2.	Select the Allowable Values node.

3.	Select the Create button.

4.	In the Value field, enter the lowest value in the range.

5.	Specify the Value Type, i.e. whether the value entered is a literal string or a database function.

6.	In the High Value field, enter the highest value in the range.

7.	Specify the High Value Type, i.e. whether the value entered is a literal string or a database function.

8.	Select the column node and set the following column properties:

−	Server Derived = Yes

−	Suggestion List = No

−	Dynamic List = No

To define a range of values against a domain:

1. 	In the Navigator, create a domain. How

2.	In the Navigator, select the domain for which a range of values is to be defined.

3.	Select the Allowable Values node.

4.	Select the Create button.

5.	In the domain Value field, enter the lowest value in the range.

6.	Specify the Value Type, i.e. whether the value entered is a literal string or a database function.

7.	In the domain High Value field, enter the highest value in the range.

8.	Specify the High Value Type, i.e. whether the value entered is a literal string or a database function.

9.	Associate columns with the domain.

−	Double click the column to which the domain values apply

−	Select the domain name from the Domain property.


About valid value constraints

Related Topics

By default, when you generate a table whose columns or associated domains are defined with allowable values, a check constraint is generated to enforce the rules on the database. The check constraint is generated as part of the table structure itself and therefore guarantees that the rule is always enforced, even if multiple applications insert or update records in the column. The allowable values can optionally be hard-coded in client applications that insert or update data in the underlying columns to perform validation on the client.

A valid value check constraint is generated when the following conditions are true:

•	the column property Dynamic List?= No

•	the table is generated with the Generate Valid Value Constraints option selected

•	the target for generation is an Oracle or DB2/2 Workbench database, or script

If you define valid values against a domain, a check constraint is generated for each column that is associated with the domain. If the target database is Oracle, valid value check constraints are prefixed AVCON_. For DB/2 Workbench the prefix is AV, due to the 18 character naming restriction.

Note:	To enforce valid value restrictions on tables on other database platforms, you should define a check constraint to perform the validation.

During generation, valid value constraints (prefixed with either AVCON_ or AV) on existing tables are automatically dropped from the database and new ones are then created in their place. This ensures that the valid value constraints on the database always match the allowable values held in the repository.

During database capture, valid value constraints (prefixed with either AVCON_ or AV) are ignored. They do not need to be captured as new ones are always created during table generation.

Example

If a column named STATUS has allowable values 'Open', 'Closed' and 'Pending', the following valid value check constraint code is generated for Oracle databases:

PROMPT Creating Check Constraint on 'ORDER_TABLE'

ALTER TABLE ORDER_TABLE

 ADD (CONSTRAINT AVCON_950722327_STATU_000 CHECK (STATUS IN ('Open', 'Closed', 'Pending')))

If the target database is DB/2 Workbench:

ALTER TABLE ORDER_TABLE ADD CONSTRAINT AV950722772_STATU_000 CHECK (STATUS IN ('Open', 'Closed', 'Pending'));

Note:	Server Generator generates constraint names internally to ensure uniqueness.


Defining data integrity constraints

Integrity constraints prevent the entry of invalid data in a table. In addition to the restrictions placed on a column by its datatype and valid value constraints, you should define the following types of integrity constraint to ensure that only valid data is entered in a column.

•	a primary key constraint for each table  How

•	foreign key constraints  How

You may also define:

•	unique key constraints to enforce uniqueness on optional columns  How

•	check constraints to provide restrictions on the type of data that can be entered in a column  How

When designing constraints for the database, there are a number of decisions to make:

•	what types of integrity constraint are needed

•	where constraints should be enforced; on the server, on both server and client or in the client only

•	whether error messages should be provided on the client if the constraint is violated  About

•	whether error messages should be written to an exceptions table  About

•	whether the constraint should be enabled or disabled  About


About data integrity

Related Topics

Data integrity describes a set of rules defined against columns to ensure that the data entered is always valid. You can define the following types of constraint:

Constraint types	Purpose
NOT NULL	Ensures a value is always provided for a column.
Primary key constraint	Ensures a value is always provided for a column, and the value is unique. A primary key constraint enables a row to be uniquely identified.
Unique key constraint	Ensures a value for a column is always unique. A value can be omitted if the unique key constraint comprises more than one column.
Check constraint	Ensures that the column value evaluates to a specific condition or is unknown.
Foreign key constraint	Ensures that a value entered for a column match an existing value in another column.
These constraints are defined as part of the table structure to ensure that the rule is always enforced on the server, irrespective of the type of application accessing the data.


Creating primary key constraints

Related Topics

There are two ways you can create a primary key:

•	create a default primary key column

Use this option if no columns exist on the table. A new primary key column is created for you, with a numeric datatype NUMBER.

•	create a primary key using an existing column

Use this option to designate a specific column as the primary key column

You can also create primary key constraints on views and materialized views that are used specifically in application design. Note however that no data definition language commands are generated for constraints defined on views or materialized views.

To create a default primary key constraint:

•	Create a default primary key constraint on a Server Model Diagram.

How

You can optionally:

•	rename the columns in the primary key

•	add columns to the primary key, or remove existing primary key columns

To create a primary key constraint using an existing column:

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	Do one of the following:

−	If the table is displayed on a Server Model Diagram, select the column to be added to the primary key

−	Hold down the right mouse button, and choose Add to Primary Key.

OR

−	In the Navigator, select the Primary Key node

−	Choose Edit→Create

3.	Choose one or more columns to be included in the primary key, by moving them to the Columns in Primary Key list box.

4.	(Optional)  Decide where the constraint is to be enforced. By default, primary key constraints are enforced on the server.

5.	Select Finish.

Next step?

Create foreign key constraints


Creating foreign key constraints

Related Topics

When you create a foreign key constraint, you can choose whether to:

•	create a foreign key to match the primary key

Use this option if you want default foreign key columns to be created for you, that match the primary key.

•	create a foreign key to match the unique key

•	create a foreign key using existing columns

Use this option to designate a specific column as the foreign key.

•	create a foreign key by creating new columns

To create a default foreign key to match the primary key:

•	Create a foreign key constraint on a Server Model Diagram. How

You can optionally:

•	rename columns in the foreign key

•	add or remove columns in the foreign key

To create a foreign key using an existing column: (custom option)

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	In the Navigator, select the Foreign Keys node for the table on which the foreign key is to be defined.

3.	Choose Edit→Create.

4.	Select the name of the join table.

5.	(Optional)  Specify whether the foreign key constraint is mandatory or optional (the default).

6.	Choose the columns on the join table that the foreign key columns will reference.

You can create a join on:

−	the primary key

−	the unique key

−	one or more existing columns

−	new columns

7.	(Optional)  Decide where the constraint is to be enforced. By default, primary key constraints are enforced on the server.

8.	(Optional)  Specify referential integrity rules.

9. 	Select Finish.


Creating unique key constraints

Related Topics

To create a unique key constraint using an existing column:

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	Do one of the following:

−	If the table is displayed on a Server Model Diagram, select the table for which the unique key is to be defined

−	Hold down the right mouse button, and choose Add Unique Key.

OR

−	In the Navigator, select the Unique Keys node

−	Choose Edit→Create

3.	Choose one or more columns to be included in the unique key, by moving them to the Columns in unique key list box.

4. 	(Optional)  Decide where the constraint is to be enforced. By default, unique key constraints are enforced on the server.

5. 	Select Finish.


Creating check constraints

Related Topics

To create a check constraint for an existing column:

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	Do one of the following:

−	If the table is displayed on a Server Model Diagram, select the table for which the check constraint is to be defined

−	Hold down the right mouse button over the table node, and choose Add Check Constraint.

OR

−	In the Navigator, select the Check Constraints node

−	Choose Edit→Create

3.	Enter a unique name for the check constraint.

4.	Select the column for which the check constraint is to be defined.

5.	Enter the check constraint condition.

Use the Add to Condition button to add the column name to the check condition.

6. 	(Optional)  Decide where the constraint is to be enforced. By default, check constraints are enforced on the server.

7. 	Select Finish.


Creating indexes

To create an index for an existing column:

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	In the Navigator, select the Indexes node under the required table and click [image].

3.	Enter a unique name for the index.

4.	Choose the type of index you want to create.

5.	Specify whether the indexed column is part of the foreign key.

6.	Choose the columns in the index.

7. 	Select Finish.


Creating synonyms

To create a synonym definition:

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	Do one of the following:

•	If the table, materialized view or cluster element is displayed on a Server Model Diagram, open the Server Model Diagram. How

−	Hold down the right mouse button over the title bar button of the required table, materialized view or cluster element, and choose Add Synonym.

OR

−	In the Navigator, select the Synonym node in the required table, materialized view or cluster element

−	Choose Edit→Create

3.	Do one of the following to record the synonym definition in the repository:

•	If a property dialog is displayed, follow the instructions on the dialog box. To get help about a dialog box field click ? and then click on the field.

•	If a property palette is displayed, enter the synonym name. Optionally, specify any additional properties. Click [image] to save the changes.

Note:	You can create both public and private synonyms. A public synonym is owned by the special user group named PUBLIC and every user in a database can access it. A private synonym is contained in the schema of a specific user who has control over its availability to others.


Creating a sequence definition

Related Topics

A sequence is an object that generates unique and serial numbers for each new row that is inserted into a column. Sequences can be associated with columns that have a numeric datatype; typically, the primary key or unique key of the table. For example, you might define a sequence to allocate employee numbers on an Employees table.

There are two types of sequence you can create.

Oracle sequence	Create sequences of this type if the target database is Oracle. An Oracle sequence can be used to generate unique numbers for columns even if rows are created concurrently, but the numbers are not guaranteed to be sequential if a statement is rolled back.
Code controls sequence	Create sequences of type code controls if the target database is not Oracle. Code control sequences guarantee unique numbers that are also sequential.
When you create a sequence, you will need to decide what type of sequence to create and whether numbers are to be generated in ascending or descending order. By default, a simple sequence definition (Oracle or code controls) will generate values that are incremented by 1. You can optionally change the increment value, and define detailed implementation details for the sequence.

To create a basic sequence definition:

1.	In the Navigator, choose Options→Use Property Dialogs.

2.	In the Navigator, select the Server Model tab.

3.	Select the Sequence Definitions node.

4.	Choose Edit→Create.

5.	Enter a unique name for the sequence.

Choose a name that indicates the columns for which the sequence will be used.

6. 	Choose the type of sequence you want to create

•	Choose an Oracle sequence if the target database is Oracle

•	Choose a Code Control sequence if the target database is another database

7.	Click Finish.

To create a detailed sequence definition:

1.	Create a basic sequence definition.

2.	In the Navigator, select the DB Admin tab.

3.	Ensure that a database definition and user definition exist for you to use.

If not, you must:

•	Create a database definition  How

then:

•	Create a user  How

4.	Expand the Database and User nodes to display the Schema Objects for the user where the sequence will be implemented.

5.	Select the Sequence Implementations node and choose Edit→Create.

6.	Choose the sequence definition you want to define in more detail.

7.	Specify any of the following types of value:

−	grant privileges on the sequence to other users and roles

−	define the sequence cycle, increment values, minimum and maximum values

8.	Click Finish.


Enabling and disabling constraints

By default, the following types of constraint are automatically enabled on the server when they are generated.

•	primary key

•	unique key

•	foreign key

•	check constraint

However, it is possible to disable a constraint by setting the Enabled property of the constraint to No.

Note: A primary key constraint must be enabled if referenced by a foreign key, which must also be enabled.


Defining error messages for constraint violations

Related Topics

You can define custom error messages against table constraints in your generated application. However, there is no need to define error messages for columns that derive their values from sequences (typically Primary or Foreign key columns) as such values will always be valid. If specific error message text is not defined for a particular constraint, the Generator provides a default message incorporating the prompts of related control.

To define an error message for constraint violation:

1.	In Navigator, double-click the constraint definition you require.

Either Primary Key, Foreign Key, Unique Key or Check Constraint.

2. 	Enter suitable Error Message text, up to 70 characters. For example,

This is not a valid extension number,

Please enter a four digit number e.g. 2334

3.	Select 'Server' from the Validate In drop-down list.

Server-side validation prevents invalid data from being stored on the server. In contrast, Client application validation will prevent the user from entering incorrect values. Validation on both sides provides the best ‘protection’ but at the expense of performance.

4. 	Click Finish to save the changes.


Maintaining data integrity using database triggers

Most of the business rules defined during database design can be automatically enforced on the Server. However, you cannot enforce referential integrity using declarative integrity constraints if child and parent tables are on different nodes of a distributed database.

Oracle allows you to enforce integrity rules with a non-declarative approach using database triggers (stored database procedures automatically invoked on insert, update, or delete operations).

The following situations may require you to write database triggers to enforce server-side business rules:

•	to provide additional referential integrity

•	distributed designs (e.g. define the trigger to enforce the referential integrity constraint across nodes in a distributed database)

•	to enforce complex business rules

•	to automatically generate derived column values

•	to provide sophisticated auditing

•	to enforce complex security authorizations

•	to prevent invalid transactions

•	to provide transparent event logging

•	to maintain synchronous table replicates

•	to gather statistics on table access

You can use both database triggers and integrity constraints to define and enforce any type of integrity rule. However, we strongly recommend that you use database triggers to constrain data input only in the following situations:

•	when a required referential integrity rule cannot be enforced using the following integrity constraints: NOT NULL, UNIQUE key, PRIMARY KEY, FOREIGN KEY, CHECK, update CASCADE, update and delete SET NULL, update and delete SET DEFAULT

•	to enforce referential integrity when child and parent tables are on different nodes of a distributed database

•	to enforce complex business rules not definable using integrity constraints

Triggers are executed automatically when an INSERT, UPDATE, DELETE or SELECT statement is issued against the data in the associated table, (i.e. when a table is modified).


Running database design reports

To be sure of having a complete database design ready for Server generation, you should carry out a full set of quality assurance checks on the database definitions, and then address any design problems these checks may produce.

The Repository Reports tool provides a number of Design Quality Check reports you can run. Their purpose is to verify the completeness of object details recorded in the repository.

The following reports can be used specifically to highlight potential problems with your database design. They are a subset of a full range of reports that you can run based on your repository definitions.

Create Status Quality Control	highlights any problems with database objects that have their create status set to Y.  About
Invalid Database Objects	highlights any problems with database objects that have been defined in the specified application system version.   About

For more information see What’s new in Repository Reports for this release?


Generating a database from a new Oracle8 object-relational design

Use the Server Modeler to develop a new Oracle8 object-relational design from scratch. Use this flowchart illustrating the design process to step through the tasks one at a time. To jump to a task, click on the appropriate step.

     Oracle8 database object


About replication

Replication is the process of copying and maintaining database objects in multiple databases that make up a distributed database system. Replication can improve the performance and protect the availability of applications because alternate data access options exist.

For example, an application might normally access a local database rather than a remote server to minimize network traffic and achieve maximum performance. Furthermore, the application can continue to function if the local server experiences a failure, but other servers with replicated data remain accessible.

Oracle database supports two different forms of replication: basic and advanced replication.

Basic replication

With basic replication, data replicas provide read-only access to the table data that originates from a primary (master) site. Applications can query data from local data replicas to avoid network access regardless of network availability. However, applications throughout the system must access data at the primary site when updates are necessary.

Oracle database can support basic, read-only replication environments using read-only table materialized views.

Advanced (symmetric) replication

The Oracle advanced replication features extend the capabilities of basic read-only replication by allowing applications to update table replicas throughout a replicated database system. With advanced replication, data replicas anywhere in the system can provide both read and update access to a table's data.

Participating Oracle databases automatically work to converge the data of all table replicas, and ensure global transaction consistency and data integrity.

Which replication to use?

If you simply need to view the data at multiple sites without updating it, you might choose to use read-only materialized views. If you need to be able to update multiple copies of the same data, use the Symmetric replication facility.


About migration to object-relational systems

Related Topics

Use the Oracle Object Type and Object View utilities to migrate a server model based on a relational table design, to an object design.  If you have not done so already, create the server model in the repository. How

Understanding the migration process

There are three key stages to migrating a relational design. Use this flowchart illustrating the process to step through the tasks one at a time. To jump to a task, click on the appropriate step.

	Create Oracle object types from the relational tables/views  Modify the default  Oracle object type definitions  Create object views for the  Oracle object types
Stage 1 - Create Oracle object types from the relational tables/views

The first stage is to build Oracle object type definitions based on the structure of the relational table/views in your current server model. How

The utility creates an Oracle object type for each selected table/view. It also creates an Oracle object type attribute for each non-foreign key column and a REF attribute for each foreign key. Note that for REF attributes to be correctly mapped to Oracle object types, both tables/views referenced by the foreign key need to be selected.

Note:	The utility also creates a set of mapping elements to record the relationship between the relational table/columns and the Oracle object type/attributes. This mapping information is used when the Oracle object types are used to implement object views for the relational table/views (see Stage 3).

Stage 2 - Modify the default Oracle object types

Once you have created a set of Oracle object types based on your relational tables/views, you can review your design from an object-orientated perspective. In this stage you will typically introduce further Oracle8 database server features. How

For example:

•	Migrate a set of attributes to new embedded Oracle object type

•	Change REF attributes to collections of VARRAY or nested table

•	Change attributes to REF attributes

•	Add/delete attributes (and column mappings)

Stage 3 - Create object views for the Oracle object types

Finally, you can build object view definitions based on the Oracle object type definitions and their mappings to relational table/views. How

The utility creates an object view  for each Oracle object type you select, together with the required SQL statements to construct the object rows from the underlying relational tables. It also creates OIDs from the underlying relational tables primary/unique key.


Creating Oracle object types from relational tables/views

Related Topics

You can create Oracle object types based on the structure of existing relational table/view definitions. This facility will help you migrate a relational server model, to an object-relational design. About

To create an Oracle object type from a relational table/view:

1.	Click the Server Model tab on the Navigator.

2.	Choose Utilities→Create Oracle Object Type

A list of available relational table/views are displayed. Tables/views from which Oracle object types have already been created are not displayed. Only one Oracle object type may be created from a particular table or view.

Note:	If you want to re-create an Oracle object type based on a relational table/view you must delete the original Oracle object type first.

3.	Move the relational tables/views for which you want to create Oracle object types, to the Process column.

4.	Click Start.

The newly created Oracle object type definitions appear in the Navigator, named <Relational_Table/View_Name>_T.

Mapping elements are also created to record the relationship between the relational table/columns and the Oracle object type/attributes. These may be viewed beneath the Oracle object type node on the Navigator, i.e. Source Table, and beneath the Attributes node i.e. Source Column, Source Foreign Key etc.

5.	Select the new Oracle object types and then choose Show on New Diagram from the right mouse button menu.

6.	To examine the new Oracle object type definitions, double-click each diagram element in turn.

Next step

Modify the default Oracle object type definitions. For example, you can introduce features such as embedded Oracle object types and collections. How

From these Oracle object types you can create object views that query object data from the relational table/views. How


Adding features to Oracle object types

Related Topics

After creating one or more Oracle object types from relational table/views, you can add further features.

For example, if the address-related properties of CUSTOMER can be reused by other Oracle object types in the server model, create a new Oracle object type called ADDRESS. Then copy the common attributes say, Address, Area, City, State, and Zip from CUSTOMER,  to ADDRESS. You can then remove these attributes from CUSTOMER and create a new embedded type attribute for ADDRESS in CUSTOMER and any other Oracle object type where ADDRESS details are required.

To add features to an Oracle object type:

1.	Display the Oracle object types on a Server Model Diagram.

Select the required Oracle object types on the Navigator and then choose Show on New Diagram from the right mouse button menu.

2.	Create additional Oracle object types, if required. How

3.	If a set of attributes are used in more than one Oracle object type:

a	Create a new Oracle object type for the common set of attributes.

b	Copy (drag and drop) the attributes into the new Oracle object type.

c	Delete the attributes from the original Oracle object type and replace them with an embedded type attribute to the new Oracle object type. How

You may also embed the new type in other Oracle object types. If the embedded type is to replace a set of attributes, then you must map the new (embedded) Oracle object type and its attributes to the original source table and columns. Use the Source Table and Source Column nodes on the Navigator to do this.

−	Expand the new Oracle object type and select Source Table. Click [image] and choose the relational table containing the source column.

−	Expand each Oracle object type attribute and select Source Column. Click [image] and choose the source column.

4.	Add methods to the Oracle object types. How

5.	By default 1:M relationships between relational tables/views are implemented as REF attributes. You can change these to collections if required.  The collections can be implemented as referenced or embedded Oracle Object Types, as VARRAYs or nested tables.

You will need to remove the REF attribute from the 'detail' Oracle object type and create a new collection REF attribute in the master Oracle object type. How

Next step

From these Oracle object types you can create object views that map back to the relational table/views. How


 Creating object views for Oracle object types

Related Topics

You can create an object view of existing relational table/view definitions. Object views can help you migrate a server model based on a relational design, to an object-relational design. About

To create an object view for a relational table/views:

1.	Click the Server Model tab on the Navigator.

2.	Choose Utilities→Create Object View

A list of available Oracle object types are displayed. Only those object types mapped to relational tables/views  are displayed in the list. How

3.	Move the Oracle object types for which you want to create object views, to the Process column.

4.	Click Start.

The newly created object view definitions appear in the Navigator, named <Relational_Table/View_Name>_T_V.

5.	To examine the object view definitions:

a	Choose Options→Use Property Dialogs

b	Double-click each element on the Navigator in turn.

The Free Format tab displays the SELECT statement specifying the base tables and columns from which the view is derived.

Next step

Generate the DDL for the object views and associated Oracle objects types. About


Ensuring data integrity during generation

You must be aware of what happens when using the CG_REF_CODES table instead of a constraint during generation:

•	When you specify a domain on a column and set the domain property Dynamic List? to Yes, the CG_REF_CODES table will be used instead of a constraint. Subsequently, during generation you do not get a warning or a message, and no code is generated to ensure the data integrity for the column with the domain.

Note:	It is the users responsibility to use the right tool to ensure data integrity.


Setting up a data source

After you have installed the ODBC driver for the type of database you want to access, you can set up one or more data sources to the required database.

This task assumes that Microsoft's ODBC Administrator is installed in your current work environment.

To set up a data source to a database:

1.	Run the ODBC Administrator.

At this point, you can install additional drivers by selecting the Drivers button from the Data Sources dialog box.

2.	In the Data Sources dialog box, select Add.

The names of all currently installed ODBC drivers are listed.

3.	Select the required ODBC driver.

4.	Enter a name and description for the data source.

5.	Specify the database to be accessed.

Note:	The type of information requested varies according to the type of ODBC driver.

6.	Select OK.

The data source is added to the list displayed in the Data Sources dialog box.

7.	Select Close to exit from the ODBC Administrator.

Next step?

You are now ready to connect to the data source when you generate the database design or Capture the design of an existing database.


Installing an ODBC driver

You can install ODBC drivers to gain access to a database using Microsoft's ODBC Administrator. Each type of database requires a specific driver.

This task assumes that the ODBC Administrator is installed in your current work environment.

To install an ODBC driver:

1.	Run the ODBC Administrator.

2.	In the Data Sources dialog box, select Drivers.

The drivers currently installed are listed.

3.	Select Add.

4.	Specify the path of the driver file. This can be a diskette, a hard disk or an area on a network.

5.	Select OK to install the driver.

Next step?

Set up a data source


Generate Server Model Definitions dialog box - Target tab

Related Topics

Identifies the target of the generation process, i.e. a DDL script file, an Oracle database, or another type of database via an ODBC driver. Select the Objects tab to choose which database objects are to be generated.

Before generating database objects, you should prepare the design for generation.  About

Caution:   Data integrity is only ensured if you generate the Table API. For example, if you have specified a domain on a column and the domain property Dynamic List? is set to Yes, a reference code table will be used to validate the domain values instead of a constraint. Hence, no constraint code is generated here to ensure data integrity for the column with the domain and no warning or message is issued during database generation.

Target for Generation options

DDL Files Only

Generates SQL CREATE statements to a set of command files based on the database objects defined in your server model.

For Oracle databases, a separate file is generated for each type of database object (table, view, trigger, etc.) and a master command file named <File_Prefix>.SQL is also generated which contains calls to all the other files. You will need to run the .SQL file against the target database, to create the objects on your target database.

Type

The type and version of your target database. This option ensures that the correct syntax is generated to create the objects on the database. The commands that can be generated vary by database type,. The options are ANSI 92, DB2, DB2/2 Workbench, Oracle (8.x and 7.x), Oracle Lite, RDB6, RDB7, SQL Server, Sybase.

Database

Generates DDL scripts to create (or alter) database objects directly on an Oracle database, using a Net8 connection. Enter the username, password and connect string for the Oracle database you want to access.  About

Username

The name of the user that must be specified to gain access to the database account. If preferred you can specify the full connect string in this field, in the format:<username>/<password>@<database>

For example, to connect to a database HQ8 using the username and password scott, you would enter: scott/scott@HQ8

If you specify the full connect string here, you do not need to complete the Password and Connect fields.

Password

The password required to connect to the database account.

Connect

The database alias required to access the database account. You must ensure that the database alias is specified in the file TNSNAMES.ORA file in your Oracle home directory, usually <oracle_home>\ NET80\ADMIN.

ODBC

Generates scripts to create (or alter) database objects directly on databases other than Oracle, via an ODBC data source.

To use this option, you must have installed an ODBC driver for the target database type and set up a data source to the required database. A specific driver is required for each type of database you want to access.

Source

Specifies the name of a predefined data source. If the data source you want is not displayed in the list, cancel this dialog box, then set up a data source to the database you want to access.  How

When you connect to an ODBC data source, you will be prompted for logon information. This information will vary depending on the type of ODBC driver you are using.

Note:	You must use a standard Oracle connection, rather than an ODBC driver, when generating to an Oracle database.

Type

Specifies the type and version of your target database. In most cases, the database type can be determined automatically when a successful connection is made. This option ensures that the correct syntax is generated to create the objects on the database. The commands that can be generated vary by database type. The options are ANSI 92, DB2, DB2/2 Workbench, Oracle Lite, RDB6, RDB7, SQL Server, Sybase.

Note:	If this option is left blank, the database type is determined from the ODBC driver. If the database type is recognized it is used, otherwise a default type is used.

File Prefix

Specifies a name for generated DDL files; up to a maximum of 237 characters. The names of previously generated files can be selected from the drop-down list.

If no prefix is specified, all generated files are named CDSDDL.*  By defining a new name, previously generated files will not be overwritten.  About

Directory

Specifies a directory for generated DDL files. The location of previously generated files can be selected from the drop-down list.

If no directory is specified, the file is written to the current working directory, by default <oracle_home>\bin.

If you specify a directory that does not exist, the utility will attempt to create a new directory of that name, when you select Start. If this process is unsuccessful, either specify an alternative target directory that does exist, or close this dialog and create the directory manually. You can use Browse to select a different directory or drive.

Stop on error

Indicates whether generation should be terminated if an error is detected.

Upload generated files to repository

To save generated files in the repository folder mapped to the directory specified in the Destination of generated files field, check this checkbox. If a repository folder is not mapped to the specified directory, the file is not saved in the repository.

For more information about saving generated files in the repository, refer to About storing generated files in the repository after generation.

Start button

To generate DDL for the selected objects, click Start.

Options button

To specify additional database generation options, click Options.


Generate Server Model Definitions dialog box - Objects tab

Related Topics

Allows you to choose which server model definitions (no user), or implementations (user-specific) are to be generated. If you have chosen to generate implementations targeted for a specific database user, the name of the user is displayed in the title bar.

Don't Generate list box

Displays the objects to be excluded from the generation process. Use the directional arrows to include or exclude an object from the list.

Generate list box

Displays the objects to be included in the generation process. Use the directional arrows to include or exclude an object from the list.

The initial contents of the list depend on the window and objects selected (Navigator or Server Model Diagram):

Navigator in focus	List populated with
Server model definitions selected  (Server Model tab).	All selected definitions. No implementation information is incorporated during generation.
User-specific implementation definitions selected  (DB Admin tab).	All selected definitions. Respective server model definitions and their implementation details are processed during generation.
User selected (DB Admin tab)	All server model implementations defined for the selected user.
PL/SQL definitions selected	All selected PL/SQL definitions. If a PL/SQL definition has Sub Program Unit(s), only the parent PL/SQL definition appears in the Generate list. The Sub Program Unit(s) are generated as part of the parent PL/SQL definition.
Container selected	All server model definitions within the selected container. No implementation information is incorporated as there is no relation to the database or the user.
Diagram in focus
One or more objects on a Server Model Diagram selected.	All selected objects on the diagram.
Directional arrows

 Generate Selection arrow

Moves selected objects to the Generate list box.

 Generate All arrow

Moves all objects of the selected type to the Generate list box.

 Don’t Generate All arrow

Moves all objects of the selected type to the Don't Generate list box.

 Don’t Generate Selection arrow

Moves selected objects to the Don't Generate list box.

Start button

To generate DDL for the selected objects, click Start.

Options button

To specify additional database generation options, click Options.


DDL Generation Complete dialog box

Related Topics

Displays post generation options.

View DDL

Displays the content of all DDL files created during generation. Choose this option if you want to examine the generated DDL before the code is executed on the chosen database.

View Report

Displays the reconcile report created during generation, i.e. <File_Prefix>.lis. Choose this option if you want to examine the differences between generated objects and those existing on the database, before executing the generated DDL.

Execute DDL

Executes the master .SQL file on the chosen database. This file contains entries to run all the generated DDL files, in the correct order. Choose this option when you are ready to create, drop or alter objects on the chosen database.

Cancel

Dismisses the dialog without executing the generated DDL.


Database Generation Options dialog box
Database Generator Options dialog box

Related Topics

Allows you to specify options that control database (DDL) generation from your server model.

General options

Generate Indexes

Indicates whether indexes defined against table/cluster/materialized view definitions are to be generated when the table, cluster or materialized view is generated.

To prevent indexes from being generated, uncheck this option.

Note:	An index cannot be generated without its associated table, cluster or materialized view.

Generate Integrity Constraints

Indicates whether integrity constraints defined against a table are to be generated when the table definition is generated, i.e. primary key constraints, unique key constraints, foreign key constraints and check constraints.

To prevent constraints from being generated when a table is generated, uncheck this option.

Note:	A constraint cannot be generated without its associated table.

Constraints defined against views are used specifically for application design, therefore no DDL commands to create constraints on views are generated.

Generate Comments

Indicates whether COMMENT ON statements are to be generated from comments defined against objects in the repository.

To prevent any comments from being generated when an object is generated, uncheck this option.

Note:	Do not confuse the Comments property (which can be generated as COMMENT ON statements) with a similar property named Description, which is used for documentation purposes only.

Automatic Creation of REF_CODES

Indicates whether reference code tables containing domain/column allowable values are to be generated automatically.

To prevent automatic generation of reference code tables, uncheck this option.

Foreign Key Generation Requires Join Table

Indicates whether one or both of the tables involved in a foreign key must be selected for it to be generated.

For generation of only the table containing the foreign key, uncheck this option.

Note:	If you previously relied on foreign keys always being generated when generating to file, you will need to uncheck this option.

Oracle Specific options

Generate Triggers

Indicates whether triggers defined against table definitions are to be generated, when the table is generated.

To prevent any triggers from being generated, uncheck this option.

Note:	A trigger cannot be generated without its associated table.

Generate Valid Value Constraints

Indicates whether check constraints are to be generated against columns that have allowable values defined against them, such as a list of values or a range of values. If allowable values are defined against a domain, a check constraint is generated against each column associated with the domain.  About

To prevent any valid value constraints from being generated, uncheck this option.

Note:	Check constraints to validate allowable values can only be generated if the column property Dynamic List? is set to No.

When generating to databases other than Oracle, you will need to define your own check constraints to validate allowable values.

To prevent check constraints from being generated, uncheck this option.

Generate Grants and Synonyms for Users and Roles

Indicates whether any GRANT privileges and SYNONYMS defined for an object are to be generated to other users and roles.

If a privilege has been granted for a user or role in another schema, a CREATE SYNONYM statement is generated for the object so that the object can be uniquely identified across different schemas.

Generate Distributed Capability

Indicates whether CREATE SYNONYM statements are to be generated for local and remote objects selected for generation. Database links to any other databases associated with the selected objects, will also be generated.

These statements are written to a distribution framework file <file_prefix>.dis, which can be run using Oracle SQL*Plus or SQLDBA to create the synonyms and database links on the Oracle database.  How

If the objects for which a synonym is to be created reside in a distributed environment, check this option.

Assign Objects to Replication Code

Indicates whether statements to associate database objects with a predefined replication group are to be generated.

If the target for generation is a database, the objects will be created in the replication group on the database. If the target for generation is a DDL script file, statements are generated to place the objects in the replication group.

Note:	The replication group itself is generated using the Generate Database Administration Objects utility.  How


Generate Database Administration Objects dialog box - Target tab

Generates CREATE statements to create database administration objects for an Oracle database.  About

The statements are written to a set of command files, called from a master command file. You can run the master command file to create the objects on the target database, using SQL*Plus or SQLDBA.  How

Note:	You will need appropriate Oracle system privileges to run the commands against an Oracle database.

Target for Generation options

File Prefix

Specifies a name for generated DDL files; up to a maximum of 237 characters. The names of previously generated files can be selected from the drop-down list.

By defining a new name, previously generated files will not be overwritten.  About

Directory

Specifies a directory for generated DDL files. The location of previously generated files can be selected from the drop-down list.

If no directory is specified, the file is written to the current working directory, by default <oracle_home>\bin.

If you specify a directory that does not exist, the utility will attempt to create a new directory of that name, when you select Start. If this process is unsuccessful, either specify an alternative target directory that does exist, or close this dialog and create the directory manually. You can use Browse to select a different directory or drive.

Database Type

The version of your target Oracle database. This option ensures that the correct syntax is generated to create the objects on the database.

For details of the differences between the commands generated for each version of the Oracle database, see Oracle databases

Database

The database definition from which administration objects are to be generated.

Generation options

Generate Create Database statement

Indicates whether a CREATE DATABASE statement for the selected database is to be generated.

If this option is unchecked, DDL statements will be generated only for selected database administration objects, such as tablespaces, rollback segments, etc.

Grant System Privileges

Indicates whether system privileges are to be generated. For example, any user, any table for selected users and role grants.

If this option is unchecked, no system privileges are generated for the selected database administration objects.

Generate Space Quotas

Indicates whether statements to grant space quotas on tablespaces are to be generated for selected users.

If this option is unchecked, no space quotas are generated.

Generate Replication Statements

Indicates whether DDL statements to replicate the structure of a master database site on one or more destination databases are to be generated, based on the selected replication group definition. You can run these statements to set up the structures on the destination databases that enable objects to be replicated from the master site.

If this option is unchecked, statements are generated to create the replication group for the master site only.

Upload generated files to repository

To save generated files in the repository folder mapped to the directory specified in the Destination of generated files field, check this checkbox. If a repository folder is not mapped to the specified directory, the file is not saved in the repository.

For more information about saving generated files in the repository, refer to About storing generated files in the repository after generation.

Start button

To generate the selected database administration objects, click Start.

To choose which objects are to be generated, select the Objects tab.


Generate Database Administration Objects dialog box - Objects tab

Allows you to choose the database administration objects to be generated.

Don't Generate list box

Displays the database administration objects to be excluded from generation. Use the directional arrows to include or exclude an object from the list.

Generate list box

Displays the objects for which DDL commands are to be generated. Use the directional arrows to include or exclude an object from the list.

Navigator (DB Admin/Distribution tab)	List populated with
Database definition	All objects associated with the database
User definition	All objects owned by the user
Selection of administration objects within the same database	All selected objects
Directional arrows

 Generate Selection arrow

Moves selected objects to the Generate list box.

 Generate All arrow

Moves all objects of the selected type to the Generate list box.

 Don’t Generate All arrow

Moves all objects of the selected type to the Don't Generate list box.

 Don’t Generate Selection arrow

Moves selected objects to the Don't Generate list box.

Start button

To generate DDL for the selected objects, click Start.


Capture Server Model from Database dialog box - Source tab

Related Topics

Indicates the source of the database capture process, i.e. an online Oracle database, DDL script files or an ODBC datasource. This dialog also allows you to specify details relating to the target container.

When the capture process is complete the new server model definitions are displayed on the Server Model tab of the Navigator. You can optionally display the new server model graphically and save the definitions to the Repository.

You can further customize the capture process by changing the initial settings of Server Generator preferences.  About

Note:	The process also capture database administration objects such as users, roles, tablespaces, etc. These captured definitions are displayed on the DB Admin tab of the Navigator, they are not viewed graphically.

Source of Design Capture

Database

Captures database object definitions from an Oracle database, via a Net8 connection. Database administration objects (tablespaces, database files, directories, rollback segments, database users, roles, profiles and replication groups) will only be displayed if the connected account has database administration privileges.

Enter the username, password and connect string for the database you want to access.  How

Username

The name of the user that must be specified to gain access to the database account. If preferred you can specify the full connect string in this field, in the format:<username>/<password>@<database>

For example, to connect to a database HQ8 using the username and password scott, you would enter: scott/scott@HQ8

If you specify the full connect string here, you do not need to complete the Password and Connect fields.

Password

The password required to connect to the database account.

Connect

The database alias required to access the database account. You must ensure that the database alias is specified in the file TNSNAMES.ORA file in your Oracle home directory, usually <oracle_home>\ NET80\ADMIN.

Owner

This is an optional field allowing you to browse and capture database objects from a user other than that specified in the Username field.

The user specified within the Username/Password fields must have the privileges necessary to allow the objects to appear in the list, e.g. SELECT.

DDL Files

Captures database object definitions from a script file containing DDL commands. The entire contents of the file are captured.  How

The file can contain the database object definitions to be captured, or can include calls to other script files that contain DDL commands. The commands must be specified in the file in the correct order.  How

Name

Specifies the path and name of the file containing the definitions to be captured. If you specify a master command file that includes other DDL scripts, all files must reside in the same directory. If no path is specified, the file is assumed to reside in the current working directory. You can use Browse to select a different directory or drive.

Type

Specifies the type of the source database (and DDL syntax) to be captured. If the database type you require is not listed, select ANSI 92.

If selected this field defaults to the database type specified in the repository database user definition into which objects are to be captured.

The types of command that can be captured varies by database type. Use the list below to determine which object types can be captured for your specified database type: ANSI 92, DB2, DB2/2 Workbench, Oracle (6, 7.x, 8.x), Oracle Lite, Rdb (6, 7), SQL Server, Sybase,

ODBC

Captures database object definitions from an ODBC data source. To use this option, you must have already installed an ODBC driver and set up a data source to the database you want to access.  How

Source

Specifies a predefined data source.

If the data source you require is not listed, cancel this dialog box, then set up a data source to the database whose definitions you want to capture.  How

Type

Specifies the type of database associated with the chosen data source. In most circumstances, the type is determined automatically when the data source is selected. The options are options are ANSI 92, DB2, DB2/2 Workbench, Oracle Lite, RDB6, RDB7, SQL Server, Sybase.

Note:	If this field is blank, the database type is determined from the ODBC driver. If the database type is recognized it is used, otherwise a default type is used.

Target Container

The target container for captured server model definitions.

Capture Implementations Into

The target database and user definition for implementation specific properties of captured objects, specified in the format:

<database_definition>.<user_definition>

Note:	If the database definition you require is not in the list, you will need to create it.  How

If the database user you require is not in the list, you will need to create it.  How

Additional Containers

Use this field to specify additional containers in which to locate objects referenced by the server model being captured. Use a comma to separate container names.

Server Generator captures the server model into the specified target container. If the objects being captured refer to other objects that are not in the target container, Server Generator attempts to locate the referenced objects by searching the specified additional containers.

Additional Containers - Browse button

To search for the containers containing referenced objects, click Browse.

Stop on error

Indicates whether the design capture process will terminate if an error is detected. For example, an error will occur if you attempt to capture a database object that is dependent on another object that cannot be captured.

Show Results on new Server Model Diagram

Indicates whether to display the captured server model elements (e.g. tables, foreign keys, views, materialized views and clusters) on a new Server Model Diagram.

To browse captured definitions using the Navigator, uncheck this option.

Capture Constraints

Indicates whether constraints defined against table definitions are to be captured into the repository, i.e. primary key constraints, unique key constraints, foreign key constraints and check constraints. To prevent constraints from being captured, uncheck this option.

Note:	A constraint cannot be captured without its associated table.

Constraints defined against views are used specifically for application design, therefore no DDL commands to create constraints on views can be captured.

Capture Indexes

Indicates whether indexes defined against table/cluster/materialized view definitions are to be captured. To prevent indexes from being captured, uncheck this option.

Note:	An index cannot be captured without its associated table, cluster or materialized view.

Capture Triggers

Indicates whether triggers defined against table definitions are to be captured. To prevent triggers from being captured, uncheck this option.

Note:	A trigger cannot be captured without its associated table.

Post Design Capture

Use these options to specify what happens when the capture process is complete.

Commit

Select this option to save captured definitions in the repository.

Note:	There are some circumstances when properties of repository objects are not updated. For more information, refer to When are repository objects not updated during generation and design capture.

Browse/Edit mode

Select this option to activate Post Processing Mode, which enables you to choose how to process proposed repository changes. For more information about Post Processing Mode, refer to About the Design Editor Post Processing Mode.

Start

To capture the database object definitions, click Start.


Capture Server Model from Database dialog box - Objects tab

Related Topics

Allows you to choose which database objects you want to capture, from the connected database.  About

Note:	Database administration objects (tablespaces, database files, directories, rollback segments, database users, roles, profiles and replication groups) will only be displayed as selectable objects for capturing if the connected account has database administration privileges.

Don't Capture

Displays the database objects owned by the connected user, that are to be excluded from the capture process. Use the directional arrows to include or exclude an object that is displayed.

Capture

Displays the database objects to be captured from the database. Use the directional arrows to include or exclude an object.

Directional arrows

 Generate Selection arrow

Moves selected objects to the Capture list box.

 Generate All arrow

Moves all objects of the selected type to the Capture list box.

 Don’t Generate All arrow

Moves all objects of the selected type to the Don't Capture list box.

 Don’t Generate Selection arrow

Moves selected objects to the Don't Capture list box.

Start button

To capture the database object definitions, click Start.