 Storing files in the repository and the Oracle Designer Generators

About repository file storage and the Oracle Designer Generators

Storing files in the repository for use during generation

About storing files in the repository for use during generation

Using files stored in the repository during generation

Storing files in the repository after generation

About storing generated files in the repository after generation

Storing generated files in the repository after generation

Capturing information from files stored in the repository

About capturing repository definitions from files stored in the repository

Capturing repository definitions from files stored in the repository


About repository file storage and the Oracle Designer Generators

Related Topics

About using the repository to store files

You can create and store files in the repository as well as in the filesystem. You can copy individual files or complete file systems into the repository (referred to as 'uploading' files). For general information about using the repository to store files, refer to About file systems in the Repository Object Navigator help system.

Using the repository to store files gives you a powerful development environment in which to create and maintain generated applications using the Oracle Designer Generators. In particular, you can:

•	store files in the repository for use during generation (Form Generator, Report Generator, Web PL/SQL Generator, Visual Basic Generator, MS Help Generator)

•	store generated files in the repository after generation (all Oracle Designer Generators)

•	store files in the repository and design capture them as repository definitions

If you store files in the repository for use during generation and also store generated files in the repository after generation, the generation process could be represented as shown below:

If you store files in the repository and design capture them as repository definitions, the design capture process could be represented as shown below:

About the benefits of repository file storage for users of the Oracle Designer Generators

Using the repository to store files enables you to:

•	use the Dependency Analyzer to identify dependent files

•	place files under version control

•	use the repository's Compare utility and Merge utility to compare and merge uploaded text files

These features simplify the tasks associated with configuration management for users of the Oracle Designer Generators who are responsible for creating, deploying and maintaining generated applications. For example:

•	a release manager can check that all the files needed for a release configuration are present

•	a development manager can identify referenced objects that do not exist in the application or repository

•	all the dependencies in an application can be documented automatically

•	a developer can find out which elements will be affected by a change to source code, and whether this may impact someone else's work


About storing files in the repository for use during generation

Related Topics

About required files used during generation

Typically, the following Oracle Designer Generators make use of a number of files (e.g. template files) during generation:

•	Form Generator

•	Report Generator

•	Web PL/SQL Generator

•	Visual Basic Generator

•	MS Help Generator

These required files can be stored on the filesystem or in the repository.

About required files stored on the filesystem

If you store the files required by the generators in the filesystem, the process of generation could be represented as shown below:

During generation:

•	the Generator requires a file during generation and searches the filesystem for the required file

•	the Generator uses the file in the filesystem during generation

•	the Generator saves the generated file to the filesystem

About required files stored in the repository

Alternatively, you can specify that when a Generator requires a file during generation, it uses the version of the required file stored in the repository. To be precise, the Generator synchronizes the file in the repository and the filesystem (i.e. the file in the repository and the file on the filesystem are made identical) and actually accesses the file on the filesystem. This process could be represented as shown below:

Before the Generator can use a file stored in the repository, you must:

•	run the Dependency Analyzer on the file stored in the repository to identify associated dependent files (if you do not want to synchronize associated dependent files, you do not have to run the Dependency Analyzer)

•	use the appropriate Generator options dialog to specify that files required during generation are saved in the repository

Having done the above, when the Generator requires a file during generation:

•	the Generator searches the repository for the required file

•	the Generator determines whether the repository file has any associated dependent files

•	the Generator compares files in the repository with files in the filesystem and synchronizes them if necessary (for more information about synchronization, refer to About synchronization in the Repository Object Navigator help system)

•	the Generator uses files in the filesystem during generation

•	the Generator saves the generated file to the filesystem

Types of file to store in the repository for use during generation

You can store the following types of files in the repository for use during generation:

Form	Report	Web PL/SQL	Visual Basic	Help
template forms (.fmb)	template reports (.tdf)	templates containing html markup	VB project files (.vbp)	graphic files (.bmp, .wmf, .mrb)
template menus (.mmb)	PL/SQL libraries (.pll)		VB form files (.frm)
object libraries (.olb)			VB library files (.bas)
PL/SQL libraries (.pll)			ctldef.txt
base HTML files (.html)
For more information...

For more information about how to store files in the repository for use during generation, refer to Uploading files or directories to the repository in the Repository Object Navigator help system.

For more information about how to generate using files stored in the repository, refer to Using files stored in the repository during generation.


Using files stored in the repository during generation

Related Topics

Prerequisites

Before you can use files during generation that are stored in the repository, you must:

•	Map a repository container to the filesystem directory in which the files are stored.

•	Upload the files to be used into the mapped container. For more information, refer to Uploading files or directories to the repository in the Repository Object Navigator help system.

•	Run the Dependency Analyzer on the uploaded files to identify associated dependent files (if you do not want to synchronize associated dependent files, you do not have to run the Dependency Analyzer). For more information, refer to Analyzing dependencies in the Dependency Analyzer help system.

To use files stored in the repository during generation:

1.	On the appropriate Generator Options dialog, specify Repository as the source of files to use during generation.

This option is on the Dependencies tab of the Form Generator Options dialog.

2.	In the Folders field, specify the folder(s) in the repository containing the files required during generation.

To specify multiple folders, separate the folder names with commas. Multiple folders are searched in the order in which you specify them.

3.	Run the Generator.

During generation, the Generator synchronizes required files (and any dependent files) in the repository with files in the filesystem.


About storing generated files in the repository after generation

Related Topics

About storing generated files after generation

All of the Oracle Designer Generators output files as a result of generation.

These files are always saved in the filesystem, and can also be saved in the repository.

About storing generated files in the filesystem after generation

The generated files output by the Oracle Designer Generators are always saved in the filesystem. This process is shown below:

At the end of a successful generation, the Generator saves one or more generated files to the filesystem.

About storing generated files in the repository after generation

As well as saving generated files in the filesystem, you can also specify that generated files are uploaded into the repository as well. This process is shown below:

At the end of a successful generation, the Generator

•	saves one or more generated files to the filesystem

•	uploads the generated files to the repository

Types of file stored in the repository after generation

You can store the following types of generated files in the repository after generation:

Form	Report	PL/SQL Web	Visual Basic	Library	Help	Database
forms (.fmb)	reports (.rdf)	SQL scripts (.sql)	VB projects (.vbp)	PL/SQL libraries (.pll)	text files (.rtf)	DDL files: - master command files (.SQL)
menus (.mmb)		package specs (.pks)	VB forms (.frm)		help project files (.hpj)	- database object command files (.tab, .ind, .trg, etc.)
		package bodies (.pkb)	VB forms in binary format (.frx)		mapping file (.hm)	- server API files (.pks, .pkb, .trg)
For more information...

For more information about how to upload generated files to the repository after generation, refer to Storing generated files in the repository after generation.


Storing generated files in the repository after generation

Related Topics

Prerequisites

Before you can store generated files in the repository, you must:

•	map a container to the filesystem directory in which the Generator will save generated files

To store generated files in the repository after generation:

1. 	Check the Upload generated output to Repository checkbox as follows:

•	For Form Generator, Report Generator, PL/SQL Web Generator, Visual Basic Generator and  MS Help Generator, choose Options→Generator Options and open the appropriate Generator Options dialog.

This option is on the Run tab of the Form Generator Options dialog.

•	For database object generation, choose Generate→Generate Database from Server Model.

•	For database administration object generation, choose Generate→Generate Database Administration Objects.

•	For table API generation, choose Generate→Generate Table API.

•	For module component API generation, choose Generate→Generate Module Component API.

•	For reference code table generation, choose Generate→Generate Reference Code Tables.

2.	Run the Generator.

•	When generation is complete, the Generator uploads generated files from the destination directory on the filesystem to the mapped folder in the repository.


About capturing repository definitions from files stored in the repository

Related Topics

About capturing repository definitions from files

You can use the following Oracle Designer Generators to capture repository definitions from files:

•	Form Generator

•	Report Generator

•	Visual Basic Generator

The files from which the Oracle Designer Generator capture repository definitions must always exist in the filesystem. In addition, the files can also exist in the repository.

About capturing repository definitions from files in the filesystem

The files captured by the Oracle Designer Generators must always exist in the filesystem. The process of capturing the files is shown below:

During design capture:

•	the Generator searches the filesystem for the file to be captured

•	the Generator captures files from the filesystem

•	the Generator creates repository definitions

About capturing repository definitions from files in the repository

Alternatively, you can specify that when a Generator captures a file, it captures the version of the file stored in the repository. To be precise, the Generator synchronizes the file in the repository and the filesystem (i.e. the file in the repository and the file on the filesystem are made identical) and actually captures the file from the filesystem. This process could be represented as shown below:

Before the Generator can capture a file stored in the repository, you must:

•	run the Dependency Analyzer on the file stored in the repository to identify associated dependent files (if you do not want to synchronize associated dependent files, you do not have to run the Dependency Analyzer)

•	specify the repository container containing the files to be captured

Having done the above, when the Generator captures a file:

•	the Generator searches the repository for the file

•	the Generator determines whether the repository file has any associated dependent files

•	the Generator compares files in the repository with files in the filesystem and synchronizes them if necessary (for more information about synchronization, refer to About synchronization in the Repository Object Navigator help system)

•	the Generator captures files from the filesystem

•	the Generator creates repository definitions


Capturing repository definitions from files stored in the repository

Related Topics

Prerequisites

Before you can capture repository definitions from files stored in the repository, you must:

•	Map a repository container to the filesystem directory in which the files are stored.

•	Upload the files to be captured into the mapped container. For more information, refer to Uploading files or directories to the repository in the Repository Object Navigator help system.

•	Run the Dependency Analyzer on the uploaded files (if you do not want to synchronize associated dependent files, you do not have to run the Dependency Analyzer). For more information, refer to Analyzing dependencies in the Dependency Analyzer help system.

To capture repository definitions from files stored in the repository:

1.	Set the appropriate registry variable under the HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/CGENF61/ key to Yes to indicate you want to capture repository definitions from file stored in the repository, as follows:

To capture definitions using this Generator:	Under registry key HKEY_LOCAL_ MACHINE/SOFTWARE/ORACLE/...	Set this registry variable to Y:
Form Generator	CGENF61	OFGCAP Repository Dependencies Flag
Library Generator	CGENF61	OLGCAP Repository Dependencies Flag
Report Generator	CGENR61	ORGCAP Repository Dependencies Flag
Visual Basic Generator	CGENV61	VBGCAP Repository Dependencies Flag
2.	Set the appropriate registry variable under the HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/ key to specify the folder(s) in the repository containing the file (and its dependent files) to capture, as follows:

To capture definitions using this Generator:	Under registry key HKEY_LOCAL_ MACHINE/SOFTWARE/ORACLE/...	Set this registry variable to the repository folder(s) containing the files to capture:
Form Generator	CGENF61	OFGCAP Repository Dependencies Source
Library Generator	CGENF61	OLGCAP Repository Dependencies Source
Report Generator	CGENR61	ORGCAP Repository Dependencies Source
Visual Basic Generator	CGENV61	VBGCAP Repository Dependencies Source

To specify multiple folders, separate the folder names with commas. Multiple folders are searched in the order in which you specify them.

3.	In the Design Editor, select Generate→Capture design of and select the option to display the Capture dialog for the type of file you want to capture.

4.	On the Capture dialog, specify the name of the file you want to capture and click the Start button to begin design capture.

During design capture, the Generator:

•	synchronizes the files (and any dependent files) in the repository with files in the filesystem

•	captures the files

•	creates corresponding repository definitions


Using Oracle Forms/Reports, Oracle Designer, and Oracle Repository together for increased productivity

About using Oracle Forms/Reports, Oracle Designer, and Oracle Repository together for increased productivity

Using Oracle Repository to source control Oracle Forms/Reports files


About using Oracle Forms/Reports, Oracle Designer, and Oracle Repository together for increased productivity

Related Topics

You can invoke the Oracle Repository check in and check out functionality from within Form Builder and Report Builder, enabling you to store files in the repository without leaving the build-time environment. Storing files in the repository gives you access to the version control, dependency analysis, and configuration management features of Oracle Repository for:

•	applications you build by hand using Form Builder and Report Builder

•	files you create with Form Builder and Report Builder that are used by the Oracle Designer Generators

Storing hand-built Oracle Forms/Reports applications in Oracle Repository

In this scenario, you create either an Oracle Forms application or an Oracle Reports application. The application is likely to comprise several files. Having saved those application files to the filesystem, you can subsequently check the files into the repository from within the appropriate build-time environment (i.e. either Form Builder or Report Builder). As part of the check in process, the files are first uploaded to the repository.

If you subsequently decide to modify the application files, you can check the files out from the repository from within the Form Builder or Report Builder. As part of the check out process, files are downloaded to the filesystem. You can then open the files in Form Builder or Report Builder and make the necessary changes.

In this way, the development process is subject to version control and configuration management. Because you can use an Oracle Repository configuration to identify the components for a particular version of an application, you can access the files required for that release at any point.

Storing Oracle Forms/Reports files required by Oracle Designer Generators in Oracle Repository

In this scenario, you create template files and library files in the appropriate build-time environment (i.e. either Form Builder or Report Builder) for use by one of the Oracle Designer Generators (i.e. either Form Generator or Report Generator).

Having saved those files in the filesystem, you can subsequently check the files into the repository from within Form Builder or Report Builder. As part of the check in process, the files are first uploaded to the repository.

You then use Form Generator or Report Generator to generate an application using the checked in template and library files. When generation is complete, the generated application files can be uploaded to the repository (and optionally checked in as well).

In this way, the entire development process is subject to version control and configuration management. Because you can use an Oracle Repository configuration to identify the components for a particular version of a generated application, you can recreate the generation environment for that release at any point.


Using Oracle Repository to source control Oracle Forms/Reports files

Related Topics

To check files into the repository from Form Builder/Report Builder

1.	Create the file using the appropriate build-time tool (i.e. either Form Builder or Report Builder).

2.	Select File→ Save to save the file to the filesystem whilst keeping the file open in Form Builder/Report Builder.

3.	Select File→Administration→ Source Control Options to display the Source Control Options dialog box and set source control options as necessary.

4.	Select File→Administration→Check in to display the Check in dialog box and set check in options as necessary.

To check files out of the repository from Form Builder/Report Builder

1.	Start the appropriate build-time tool (i.e. either Form Builder or Report Builder).

2.	Open the file in Form Builder/Report Builder.

3.	Select File→Administration→ Source Control Options to display the Source Control Options dialog box and set source control options as necessary.

4.	Select File→Administration→Check out to display the Check out dialog box and set check out options as necessary.


Domain table support

About domain tables

Defining domain tables

Using domain tables

Examples of the use of domain tables

Notes on the use of domain tables


About domain tables

Related Topics

About domain tables

A domain table contains one or more sets of valid values. Typically an application might use a domain table to provide:

•	dynamic lists of valid selectable values for LOVs, pop lists, text lists and combo boxes

•	field validation

About domain tables and reference code tables (including the CG_REF_CODES table)

The important difference between domain tables and reference code tables is what is modeled in the repository:

In the case of domain tables, it is the domain table itself that is modeled in the repository. The table is like any other table defined in the repository. It is your responsibility to define the columns you want in the table and to generate the table using Server Generator. It is also your responsibility to enter data into the domain table. The domain table is not populated with allowable values defined in the repository (in particular, a domain table has no connection with domains defined in the repository). Because the domain table is modeled in the repository, you can join it to other table definitions modeled in the repository.

In the case of reference code tables, it is the data (i.e. the allowable values) that is modeled in the repository. A reference code table itself is not modeled in the repository. The Server Generator automatically generates a reference code table when it detects that allowable values have been defined for a column (either directly against the column or against a domain with which the column has been associated). All reference code tables contain the same columns. If one reference code table is created for all containers (i.e. all folders and application systems), the table is called CG_REF_CODES and contains valid values and ranges for columns and domains from all containers.

You can see that using a domain table instead of a reference code table gives you more flexibility (you can define the columns you want in the domain table) but requires more maintenance (you are responsible for entering data into the domain table).


Defining domain tables

Related Topics

How to define a domain table

1.	Create a repository definition of the domain table in the same way that you would define any table.  How

2.	Generate the domain table in the same way that you would generate any table.  How

3.	Populate the domain table with data.

Hint: Create a module with a base table usage of the domain table and generate an application to enter the data.

4.	Define domain key constraints between other tables and the domain table as required.  How

5.	Create usages of the domain table as required.  How


Using domain tables

Related Topics

How to use a domain table

1.	Create domain key constraints for those tables containing columns that you want to populate from or validate against the domain table.  How

2.	If the domain table contains multiple sets of allowable values, set each domain key constraint's WHERE condition property to identify the correct allowable values.

3.	If the domain table contains allowable values that have different datatypes to the base table columns into which they will be inserted, use the Conversion Format Mask property of columns comprising domain key constraints to specify the format mask to use when converting values to the correct datatypes.

For more information about when to use the Conversion Format Mask property, refer to Notes on the use of domain tables.

4.	If you specified that the domain key constraints on particular tables are to be validated on the server, generate the Table API for those tables.

5.	Create a module with a module component that has a base table usage of a table joined to the domain table by a domain key constraint.

6. 	Create an item based on the domain key column in the base table (i.e. the column that forms the join to the domain table).

If the domain constraint's Validate In property is set to Client or Both, code in the generated application validates the value entered in this item against the values in the domain table.

7.	(Form Generator and Web PL/SQL Generator only) To display values from the domain table in an LOV:

a.	create a repository LOV definition with an LOV table usage of the domain table

b.	associate the repository LOV definition with an item

c.	(optional) further restrict the values in the LOV using the appropriate WHERE condition properties

The above instructions do not apply to Visual Basic Generator, which generates LOVs without the need to explicitly define them.

8.	(Form Generator and Web PL/SQL Generator only) To display values from the domain table in a list item:

a.	create a lookup usage of the domain table and link it to the base table usage via the domain key constraint

b.	create a lookup item based on the column in the domain table that is linked to the base table

c.	set the base table item's Display property to No

d.	set the lookup item's Display property to Yes and the lookup item's Display Type property to one of Poplist or Text List

Note that you can also populate a list item with values from a domain table by defining a repository LOV definition with a usage of the domain table. For more information, refer to the appropriate topic below:

•	for Form Generator, About generated lookup poplist, lookup text list and lookup combo box items.

•	for Web PL/SQL Generator, About generated lookup poplist and lookup text list items.


Examples of the use of domain tables
Examples of the use of a domain table

Related Topics

Examples of the use of a domain table

For the examples, two tables have been defined.

A domain table called ALL_DOMAINS has been defined with three columns Category, Value, and Meaning. The columns Category and Value form the primary key. The domain table has been populated with two sets of values:

•	the jobs category contains valid jobs and descriptions

•	the travel_class category contains valid travel classes and descriptions

A table called EMP has been defined with three columns Empno, Ename, Jobname. A domain key constraint EMP_ALLDOM_DK has been defined on EMP linking EMP.Jobname with ALL_DOMAINS.Value. To identify the valid values in ALL_DOMAINS, the domain key constraint's Where Condition property is set to CATEGORY='jobs'. The Validate in property of EMP_ALLDOM_DK is set to Client.

Example 1: field level validation using a domain table

This module contains a base table usage of EMP.

Because the Validate in property of EMP_ALLDOM_DK is set to Client, the generated application prevents users entering values in the Job name field that are not in the domain table with a category of 'jobs'.

Example 2: poplist item populated using a domain table

This module contains a base table usage of EMP and a lookup table usage of the domain table ALL_DOMAINS.

The  EMP_ALLDOM_DK domain key constraint ensures that the lookup poplist item Jobname is populated from those rows in the ALL_DOMAINS table with a category of 'jobs'. To generate a lookup poplist item, item properties are set as follows:

Item	Display	Prompt	Display type
EMP.Jobname	No	-	-
ALL_DOMAINS.Category	No	-	-
ALL_DOMAINS.Value	Yes	Job Name	Poplist

Note that you can also populate a list item with values from a domain table by defining a repository LOV definition with a usage of the domain table. For more information, refer to the appropriate topic below:

•	for Form Generator, About generated lookup poplist, lookup text list and lookup combo box items.

•	for Web PL/SQL Generator, About generated lookup poplist and lookup text list items.

Example 3: LOV populated using a domain table

This module contains a base table usage of EMP and an LOV called JOBS_LOV with a table usage of ALL_DOMAINS. The Additional Restriction property of JOBS_LOV is set to Value like '%c%'.

The values in the LOV are restricted both by the Where Condition of the EMP_ALLDOM_DK domain key constraint and by the Additional Restriction property of JOBS_LOV.


Notes on the use of domain tables
Notes on the use of a domain table

Related Topics

Converting datatypes

If the domain table contains allowable values that have different datatypes to the base table columns into which they will be inserted, use the Conversion Format Mask property of columns comprising domain key constraints to specify the format mask to use when converting values to the correct datatypes.

For example, a domain table might contain multiple sets of allowable values in a VARCHAR2 column. One set of allowable values might be dates, a second set might be numbers, and a third set might be text strings. Assume these values are to be inserted into base table columns with date, number and text datatypes respectively. The Conversion Format Mask property enables you to specify the date or number format mask used when the non-text values are converted to the correct datatype.

If you do not set the Conversion Format Mask property, the Generators determine the format mask to use as follows:

•	when converting a VARCHAR2 value in a domain table to a valid date:

if	the column in the domain table has a format mask, use that
otherwise if	the column in the base table has a format mask, use that
otherwise	use FMYYYY-MM-DD
•	when converting a VARCHAR2 value in a domain table to a valid number:

if	the column in the domain table has a format mask, use that
otherwise if	the column in the base table has a format mask, use that
otherwise	use FM9999999999999999.9999999999999999

Note that if a single column in a domain table contains allowable values of different datatypes and you do not set the Conversion Format Mask property of columns comprising the domain key constraints, you must not set the Format Mask property of the column in the domain table. Either set the Format Mask property of each base table column using the domain table, or make sure the above defaults are acceptable.


Using the Oracle Designer Generators with a versioned repository

Versioned repositories for users with experience of the Oracle Designer Generators in non-versioned environments

Creating and updating repository objects during generation and design capture

When are repository objects not updated during generation and design capture

Generating applications from a versioned repository

Capturing applications into a versioned repository


Versioned Repositories for users with experience of the Oracle Designer Generators in non-versioned environments

Related Topics

Using the Oracle Designer Generators to generate from and capture to a versioned repository is very similar to generating from and capturing to a non-versioned repository.

If you have used the Generators with non-versioned repositories, you will see one major difference with a versioned repository. The Generators only update properties of a versionable repository object if one of the following conditions is true:

•	you have already checked out the object

•	the Generator can check out the object (using the Auto-Checkout feature)

•	the object is not versioned (i.e. it has never been checked in)

Generation (but not capture) continues even if versionable repository objects cannot be updated. For a full list of versionable repository objects, refer to Versionable objects.

During generation, messages in distinctive colors indicate whether the Generators have successfully updated repository objects. Note that a Generator's attempt to update an object can fail for a number of reasons besides not being able to access checked in objects (for more information, refer to When are repository objects not updated during generation and design capture).

In a versioned repository, a workarea's specification (i.e. the workarea's configurations and/or workarea rules) determines which versions of which objects are visible within the workarea. When defining the specification for a workarea, it is your responsibility to make sure that the correct versions of the correct objects are visible in the workarea. The Generators are unlikely to generate a module successfully if a module references an object that is not visible in the current workarea.

If you are not sure that the correct versions of the correct objects are visible, use the List External References utility in the Repository Object Navigator.

Tools, utilities and features to support generation from versioned Repositories

Tool/Utility/Feature	Use to:
Version Event Viewer	view the event information recorded for different versions of an object
Version History Viewer	view the evolution of a repository object graphically as a series of nodes
List External References utility	determine whether the correct versions of the correct objects  necessary for successful generation are visible
Auto-Checkout feature	specify that a Generator is to automatically check out all repository objects required during generation or design capture.


Creating and updating repository objects during generation and design capture

Related Topics

During generation, the Designer Generators might detect that a property of a repository object is set incorrectly. To continue generation, the Generators assume an appropriate value for the property. Using the following options on the Generate dialog box, you can specify whether a Generator attempts to update repository object properties with corrected values:

•	Commit - update repository objects

•	Revert - do not update repository objects

•	Browse/Edit - show proposed repository changes, enabling you to choose how to process them

During design capture, you might instruct a Generator to use the module being captured to create a new repository module definition or to update an existing repository module definition. Using the following options on the Capture dialog box, you can specify whether the Generator attempts to create or update repository objects immediately or enables you to view the proposed changes before applying them:

•	Commit - update repository objects

•	Browse/Edit - show proposed repository changes, enabling you to choose how to process them

If the Generator is using the module being captured to update an existing repository module definition, the Generator will attempt to update the properties of repository objects belonging to the module. In some circumstances, the Generators will not update object properties (for more information, refer to When are repository objects not updated during generation and design capture).


When are repository objects not updated during generation and design capture?

Related Topics

Using options on the Generate dialog box and the Capture dialog box, you can specify whether the Generators are to update the properties of a repository object.

However, regardless of those options, the Generator will not update properties of repository objects in the following circumstances:

•	the object has been updated or deleted by another user

•	the object is currently locked for update by another user

•	you do not have appropriate access rights to query or update the repository object containing the object (e.g. the module containing the specific module component)

•	the object is a reusable module component or reusable LOV (with one exception - the MS Help Generator can always update the Help Context Id Prefix property of reusable module components)

•	the object belongs to a reusable module component or reusable LOV

•	the object belongs to a module that has a language different to the module itself

•	the object belongs to a module of a language different to that expected by the Generator (i.e. you have selected Generate→Generate as)

•	generation has been unsuccessful, in which case no properties are updated

•	(versioned repository only) the object belongs to a repository object that is currently checked in and the Auto-Checkout feature is not enabled

•	(versioned repository only) although the object belongs to a checked in repository object in the current workarea and the Auto-Checkout feature is enabled, the object cannot be checked out for one of the following reasons:

−	you do not have appropriate access rights to check out the object

−	the Auto-Checkout feature attempts to check out objects with a lock (either because you have specified that is how you want the Auto-Checkout feature to work, or because a strict locking policy has been applied to the repository), but is unable to do so because the object is already checked out with a lock in another workarea

•	(versioned repository only) the version of the repository object to which the object belongs that is visible in the workarea is different to the version of the object used by the Generator during generation or design capture, due to one of the following:

−	the re-specification or refreshing of the workarea

−	the checkout of the object by another user in the same workarea


Generating applications from a versioned repository

Related Topics

If you are using the Designer Generators to generate applications from a versioned repository, there are some specific considerations to be aware of.

•	The Generators operate on the versions of repository objects visible in the current workarea. When defining the specification for a workarea, it is your responsibility to make sure that the correct versions of the correct objects are visible in the workarea. The Generators are unlikely to generate a module successfully if a module references an object that is not visible in the current workarea.

If you are not sure that the correct versions of the correct objects are visible, use the List External References utility.

•	During generation from both a versioned repository and a non-versioned repository, a Generator might determine that a property of a repository object is incorrectly set or has not been set at all. Depending on options you set prior to generation, the Generator might attempt to update the properties of repository objects.

However, when generating from a versioned repository, the Generator can only update an object's properties if the object is currently checked out. Prior to generation, you can:

−	manually check out all objects you think the Generator might need to update

−	use the Auto-Checkout feature to specify that the Generator is to automatically check out all objects required during generation (for more information, refer to About Auto-Checkout)

Note that if a Generator cannot update a repository object, generation continues but no further updates are attempted.

When generation is complete, the Generator issues messages to indicate those changes that were successfully attempted (i.e. where Repository object properties were updated) and those changes that were unsuccessfully attempted (i.e. where Repository object properties were not updated).


Capturing applications into a versioned repository

Related Topics

If you are capturing applications into a versioned repository (i.e. using Form Generator, Report Generator, Library Generator, or Visual Basic Generator), there are some specific considerations to be aware of.

•	The Generators operate on the versions of repository objects visible in the current workarea. When defining the specification for a workarea, it is your responsibility to make sure that the correct versions of the correct objects are visible in the workarea.

•	The Generators capture objects into a target container. Note that the design capture process cannot continue if the target container is checked in.

•	If the repository objects being captured refer to other objects (e.g. tables, languages, attached libraries, reusable module components, reusable LOVs) that are not in the target container, you can specify additional containers in which the Generators can find the referenced objects. Note that:

−	the Generators do not update or create referenced objects in additional containers during design capture

−	referenced objects must be visible in the current workarea

•	If you are using the module being captured to modify an existing repository module, it is likely that the Generators will attempt to update the properties of objects belonging to the existing module.

However, when capturing into a versioned repository, a Generator can only update an object's properties if the object is currently checked out. Prior to design capture, you can

−	manually check out all objects you think the Generator might need to update

−	use the Auto-Checkout feature to specify that the Generator is to automatically check out all objects required during the design capture process (for more information, refer to About Auto-Checkout)

Note that if a Generator cannot update a repository object, an error message is displayed and design capture is halted.


Generating Year 2000 compliant applications

About the Year 2000 (Y2K) problem

About Y2K-compliant date format masks

About Server Generator and Y2K compliance

About Form Generator and Y2K compliance

About Report Generator and Y2K compliance

About Library Generator and Y2K compliance

About WebServer Generator and Y2K compliance

About Visual Basic Generator and Y2K compliance


About the Year 2000 (Y2K) problem

Related Topics

The 'Year 2000 Problem' (often abbreviated simply to 'Y2K') is a term used to describe the implications upon computer systems of the date change that will occur on 1st January 2000. Applications that have been written assuming a date format that includes a two digit year are likely to fail, cause data corruption, or behave unpredictably. For example, a system that compares dates using two digit years will determine that 2001 is earlier than 1999 because 01 is less than 99. To give just one example, this incorrect result could cause an inventory-control application to discard stock because its 'Use by date' appears to have been exceeded.

To correct the Y2K problem, many enterprises are rewriting existing applications or implementing new applications to take account of the date change. Clearly, using a four digit year is likely to form part of any solution, but additional work might also be required.

A term given to systems that will not be affected by the date change is 'Y2K-compliant'. All of Oracle's current development tools and database products are Y2K-compliant. However, it is your responsibility to ensure that the applications you build using Oracle's tools are fully Y2K-compliant.

The Oracle Designer Generators will help you to create Y2K-compliant applications, providing you follow a number of guidelines and use Y2K-compliant date formats when necessary.


About Y2K-compliant date format masks

Related Topics

What are Y2K-compliant date format masks?

You can use Y2K-compliant date format masks to avoid many of the issues associated with the Y2K problem. For a date format mask to be Y2K-compliant, the year element must be set to one of the following:

•	YYYY

•	RRRR

•	RR

The above list is ordered according to recommended usage. The YYYY format mask is often preferable to force users to enter a full and unambiguous date format.

Where an application is used for large amounts of data entry, allowing users to type just two digits might be a requirement. Specifying the RRRR date format mask allows users to enter four digit years. However, if a user enters only two digits, the initial two digits are defaulted according to the entered digits and this defaulting is visible to the user. If the number entered was 49 or below, the initial two digits default to the later century (e.g. 20). If the number entered was 50 or above, the initial two digits default to the earlier century (e.g. 19). So if a user typed 12, the date defaults to 2012. If a user typed 92, the date defaults to 1992.

The RR date format mask is usually the least preferable of the Y2K-compliant date format masks. Users can enter and view only two digits. Internally, the initial two digits are defaulted in the same way as for RRRR. However, the defaulting is not visible to users who only see the two digits they entered. Use this date format mask when there is limited screen 'real-estate', or when upgrading applications where the year field must occupy the same width as a non-Y2K-compliant date format mask (i.e. YY).

Examples of Y2K-compliant date format masks include the following:

•	DD-MON-YYYY

•	MM-RRRR

•	MM-DD-RR

What are non-Y2K-compliant date format masks?

If the year element of a date format mask is set to YY, the format mask is not Y2K-compliant. We strongly recommend you never use date format masks that include YY as the year element.

Examples of non-Y2K-compliant date format masks include the following because they use YY as the year element:

•	DD-MON-YY

•	MM-YY

•	MM-DD-YY

The only occasion on which you might consider using non-Y2K-compliant date format mask might be as the format mask for a read-only item (e.g. in a generated report). In this case, the YY and RR format masks (and the YYYY and RRRR format masks) are equivalent. Even in read-only applications, we recommend you use a four digit format mask to avoid any possible ambiguity.


About Form Generator and Y2K compliance

Related Topics

Form Generator enables you to generate forms that are fully Y2K-compliant. However, the responsibility to generate Y2K-compliant forms is shared between you and Form Generator when:

•	setting properties of generated objects

•	entering code

Properties to support Y2K compliance

What properties does Form Generator set to support Y2K compliance?

During generation, Form Generator increases the Maximum Length property of a date item if it is insufficient to display a date in the specified date format.

To take full advantage of date formatting enhancements made in Oracle Forms, Form Generator also sets the Runtime Compatibility Mode property of generated form modules to the most recent version of Oracle Forms.

If Form Generator cannot determine the date format mask to use for an item (i.e. no format mask is specified in the repository, template, object library, or by the preferences TXTDDF/TXTDTF), Form Generator sets the item's Format Mask property using an internal Y2K-compliant date format mask.

What properties are your responsibility when supporting Y2K compliance?

It is your responsibility to:

•	specify a Y2K-compliant format mask for an item

•	set a date item's Display Width property sufficiently wide to display a Y2K-compliant date format mask

•	make sure the Maximum Length and Display Width properties of 'non-date' items containing date information are set correctly

For example, you might create an unbound item of type Text to display a literal string that also contains within it a date passed as a parameter to the called form. It is your responsibility to ensure that the unbound item's Width and Maximum Length properties are sufficient to display the date in a Y2K-compliant format.

•	use the same Y2K-compliant date format mask that is specified for an item when defining a date as the item's Default Value property

•	use the same Y2K-compliant date format mask that is specified for an item when defining allowable values (and ranges of allowable values) for the item

Code to support Y2K compliance

General guidelines for Y2K-compliant code

Form Generator includes code in all generated forms to support Y2K-compliance. But when converting character strings to dates (and dates to character strings), you will have to consider whether to use an explicit date format. Base your decision about using an explicit date format on whether the date/character string conversion is 'external' or 'internal'.

•	An 'external date/character string conversion' is the term used to describe the conversion of a date to a character string (or a character string to a date) when the source or result of this conversion is visible to the user. When performing external date/character string conversions, always specify an explicit date format mask. For example, a literal string displayed to the user might contain a date passed as an argument to a called form. Because the date will be visible to the user, it should be converted to a character string using an explicit date format.

•	An 'internal date/character string conversion' is the term used to describe the conversion between a date and a character string (or between a character string and a date) when neither the source nor the result of this conversion are visible to the user. When performing internal date/character string conversions, always rely on the default date format mask created by Form Generator in the PRE-FORM trigger to preserve all date information.

Relying on the default date format mask ensures that the first two digits of a year are not discarded during conversions between dates held as dates and dates held as character strings. Only override the default date format mask when you want a date visible to the user to be in a different format to the default date format mask (e.g. perhaps because the default date format mask contains too much information).

What code does Form Generator create to support Y2K compliance?

Form Generator includes code in the PRE-FORM trigger of every generated form to define a 'default date format mask' with a four digit year element. The default date format mask is YYYY/MM/DD HH24:MI:SS. Using the default date format mask ensures that all date information is preserved during date/character string conversions. If a date format mask is not explicitly specified, this default date format mask is used  for built-in, PL/SQL, and database operations.

Form Generator follows the guidelines for Y2K-compliant code and ensures all generated application logic is Y2K-compliant by:

•	relying on the default date format mask (as created in the PRE-FORM trigger) for all internal date/character string conversions to preserve all date information

•	explicitly specifying Y2K-compliant date format masks for all external date/character string conversions to ensure that dates visible to the user are in the intended format

The code in the PL/SQL libraries, object libraries, and templates supplied with Form Generator also follows these guidelines.

What code is your responsibility when supporting Y2K compliance?

It is your responsibility to follow the guidelines for internal and external date/character string conversion when entering your own code as:

•	user-defined application logic

•	template application logic

•	object library application logic

•	user-modified generated application logic

•	summary functions

•	repository properties (e.g. Derivation Expression property of columns, Derivation Text property of unbound items, PL/SQL Block property of items)

•	code in PL/SQL libraries attached to the generated form

In other words when performing internal date/character string conversions in any of the above, rely on the default date format mask. When performing external date/character string conversions, explicitly specify a Y2K-compliant date format mask.


About Report Generator and Y2K compliance

Related Topics

Report Generator enables you to generate reports that are fully Y2K-compliant. However, the responsibility to generate Y2K-compliant reports is shared between you and Report Generator when:

•	setting properties of generated objects

•	entering code

Properties to support Y2K compliance

What properties does Report Generator set to support Y2K compliance?

If Report Generator cannot determine the date format mask to use for an item or parameter (i.e. no format mask is specified in the repository, template, object library, or by the preference DTEMSK), Report Generator sets the Format Mask property of the item or parameter to a Y2K-compliant date format mask.

Report Generator increases the Width property of a date parameter if it is insufficient to display a date in the specified date format mask.

What properties are your responsibility when supporting Y2K compliance?

It is your responsibility to:

•	specify a Y2K-compliant format mask for date items and parameters

•	set the Width property of date items and parameters sufficiently wide to display a Y2K-compliant date format mask

•	make sure the Width properties of 'non-date' items and parameters containing date information are set correctly

For example, you might create an unbound item of type Text to display a literal string that also contains within it a date passed as a parameter to the called report. It is your responsibility to ensure that the unbound item's Width properties are sufficient to display the date in a Y2K-compliant format.

•	use the same Y2K-compliant date format mask that is specified for an item or parameter when defining a date as the Default Value property of the item or parameter

•	use the same Y2K-compliant date format mask that is specified for an item or parameter when defining allowable values (and ranges of allowable values) for the item or parameter

Code to support Y2K compliance

General guidelines for Y2K-compliant code

Report Generator includes code in all generated reports to support Y2K-compliance. However, you must always explicitly specify a date format mask to use when converting character strings to dates (and dates to character strings). Base your decision about which format mask to use on whether the date/character string conversion is 'external' or 'internal'.

•	An 'external date/character string conversion' is the term used to describe the conversion of a date to a character string (or a character string to a date) when the source or result of this conversion is visible to the user. When performing external date/character string conversions, always explicitly specify a Y2K-compliant date format mask. For example, a literal string displayed to the user might contain a date passed as an argument to a called report. Because the date will be visible to the user, it should be converted to a character string using an explicit date format.

•	An 'internal date/character string conversion' is the term used to describe the conversion between a date and a character string (or between a character string and a date) when neither the source nor the result of this conversion is visible to the user. When performing internal date/character string conversions, always use the YYYY/MM/DD HH24:MI:SS date format mask.

Using the YYYY/MM/DD HH24:MI:SS format mask ensures that the first two digits of a year are not discarded during conversions between dates held as dates and dates held as character strings. Only use an alternative date format mask when you want a date visible to the user to be in a different format (e.g. perhaps because the YYYY/MM/DD HH24:MI:SS date format mask contains too much information).

What code does Report Generator create to support Y2K compliance?

Report Generator follows the guidelines for Y2K-compliant code and ensures all generated application logic is Y2K-compliant by:

•	explicitly specifying the YYYY/MM/DD HH24:MI:SS date format mask for all internal date/character string conversions to preserve all date information

•	explicitly specifying Y2K-compliant date format masks for all external date/character string conversions to ensure that dates visible to the user are in the intended format

The code in the PL/SQL libraries and templates supplied with Report Generator also follows these guidelines.

What code is your responsibility when supporting Y2K compliance?

It is your responsibility to follow the guidelines for internal and external date/character string conversion when entering your own code as:

•	user-defined application logic

•	template application logic

•	user-modified generated application logic

•	repository properties (e.g. Derivation Text property of unbound items)

•	code in PL/SQL libraries attached to the generated report

In other words when performing internal date/character string conversions in any of the above, explicitly specify the YYYY/MM/DD HH24:MI:SS date format mask. When performing external date/character string conversions, explicitly specify a Y2K-compliant date format mask.


About Library Generator and Y2K compliance

Related Topics

Library Generator enables you to generate fully Y2K-compliant PL/SQL library modules for use by Oracle Forms and Oracle Reports applications. However, it is your responsibility to enter Y2K-compliant code for inclusion in generated PL/SQL libraries.

What code is your responsibility when supporting Y2K compliance?

It is your responsibility to follow the guidelines for internal and external date/character string conversion when entering your own code according to how the generated PL/SQL library module will be called.

If the generated PL/SQL library module will only be called by Oracle Forms applications, follow the guidelines for entering Y2K-compliant code for form generation. This will enable you to rely on the default date format mask generated into the PRE-FORM trigger for 'internal' date/character string conversions. For more information, refer to About Form Generator and Y2K compliance.

If the generated PL/SQL library module will only be called by Oracle Reports applications, or will be called by both Oracle Reports and Oracle Forms applications, follow the guidelines for entering Y2K-compliant code for report generation. Report Generator does not create a default date format mask, so you must use an explicit date format if the PL/SQL library module will be called from generated Oracle Reports applications. For more information, refer to About Report Generator and Y2K compliance.


About WebServer Generator and Y2K compliance

Related Topics

WebServer Generator enables you to generate applications that are fully Y2K-compliant. However, the responsibility is shared between you and WebServer Generator when:

•	setting date format masks for bound/unbound items

•	entering code

Date format masks

When defining format masks for date items, it is your responsibility to:

•	specify a Y2K-compliant format mask for a bound, or unbound item i.e. YYYY, RRRR, RR

Tip:	Use the Default date format for date fields (TXTDDF) preference to set up a default date format for your generated application.

•	set a date item's Display Width property sufficiently wide to display a Y2K-compliant date format mask

•	use the same Y2K-compliant date format mask that is specified for an item when defining a date as the item's Default Value property

Note: 	If no date format mask is specifically defined, the NLS Date Format of the WebServer (DCD or DAD) is used instead. If a new NLS Date Format is defined, you will have to re-start the Web Listener and Web Request Broker for the change to take effect.

•	use the same Y2K-compliant date format mask that is specified for an item when defining allowable values (and ranges of allowable values) for the item

User-defined code

When entering your own code, it is your responsibility to enter string to date conversions with an explicit format mask i.e. one that will preserve the full year. For example, if you enter code as:

•	user-defined application logic written in PL/SQL

•	user-defined application logic written in JavaScript
Date fields in JavaScript are manipulated as strings. You will need to ensure that the string being used matches the date format mask that is defined.

•	repository properties (e.g. Derivation Expression for columns, Derivation Text for unbound items etc.)


About Visual Basic Generator and Y2K compliance

Related Topics

Visual Basic Generator generates applications that are fully Y2K-compliant i.e. all date conversions handle four digits of a year.

Note:	Visual Basic Date formats are taken from the Windows Control Panel (Regional Settings).

 If you enter your own code however, it is your responsibility to enter string to date conversions that will preserve the full year. For example, if you enter code as:

•	user-defined application logic

•	user-modified generated application logic

•	template application logic

•	repository properties (e.g. Derivation Expression for columns, Derivation Text for unbound items etc.)