Oracle9i Designer Migration Guide Part 1. Introduction, enhancements and new features |
Contents

# Chapter 1 Introduction

This migration guide provides essential information for those who wish to migrate to Oracle9i Designer from Oracle Designer 1.3.2, 2.0 or 6.0. A previously published guide covered migration to Oracle Designer 6i. Migration from Oracle Designer 6i to Oracle9i Designer is unnecessary because certain 6i and 9i repositories are compatible, as follows:

- Designer/SCM 9i 9.0.2.0 has same repository level as 6i 4.2 (4.0.12.80.6)
- Designer/SCM 9i 9.0.2.1 has same repository level as 6i 4.3 (4.0.12.88.2)

This means that if you wish to transfer from 6i to 9i:

- from 6i 4.2 to 9.0.2.0 is a client change only, so no repository upgrade is required
- from 6i 4.2 to 9.0.2.1 requires a client change and repository upgrade
- from 6i 4.3 to 9.0.2.1 is a client change only, so no repository upgrade is required.

Note that you cannot transfer from 6i 4.3 to 9.0.2.0 because 9.0.2.0 is a lower repository version level than 6i 4.3.

## Benefits and reasons for migrations

Oracle9i Designer offers the following recent enhancements:

- version control of repository objects
- workspace management (workareas)
- storage of text and binary files
- support for release management (via configurations)
- impact analysis tool (dependency analyzer)
- support for Oracle 9i, Oracle Reports 9i and Oracle Forms 9i
- support for repository management operations via an extended API
- support for repository management batch operations via a command line tool

Note: At the time of writing, Oracle9i Designer is certified with Oracle database 81700 or higher, and with Oracle9i patched to 9.0.1.2. See metalink.oracle.com for the latest situation.

Specifically, the option of version control of repository objects and related functionality (e.g. workspaces, configurations and storage of file system) offers the following non-tangible benefits:

- improvement of the functionality of the client generators (e.g. Oracle Forms 9i, ) and server generators (e.g. support for Oracle9i).
- introduction of a configuration management solution that is fully supported with a standard Oracle tool set (instead of a solution with a third party source control tool (e.g. PVCS/VM, ClearCase)
- the availability of a single repository that captures structured elements and files during the complete lifecycle. A single repository fully supports model-based development and deployment and therefore improves the quality of the development and deployment process.

You could also identify the following tangible benefits as a result of adopting Oracle9i Designer:

- More efficient method to detect, analyze and solve issues via rich impact analysis tools (Dependency Manager)
- More efficient effort to build and verify multiple releases
- More efficient method to merge different releases (compare and merge facilities)
- More efficient method for building delta scripts via accuracy of the repository and richer supporting tools (DDL generator

Given this new functionality and benefits you may want to adopt Oracle9i Designer for one or more of the following reasons:

- Flexible and effective support of development of multiple releases simultaneously
- Effective prototyping tool – easy to create and store multiple alternatives via the version mechanism
- Synchronization between the logical and physical data model in Designer
- Synchronization between the database model implementation and the database definitions in Designer – high quality of meta data
- Usage of versions strings to effectively verify the database objects against the repository content
- Improvement of impact analysis capability - including the storage of column dependencies
- Improvement of functionality and performance of the creation/generation of database delta scripts
- Actualization of the current Designer tool stack to latest available technology.
- Cost effective access to resources for development and support (Oracle9i Designer/Developer 9i experts as opposed to Designer 1.3.2/Developer 4.5 experts)
- Provide a widely shared development and deployment environment
- Recognition of configuration management needs (multiple releases, release and build management)

The above mentioned benefits, offered by the new functionality, can be attained only by migrating your structured data (captured in application systems in previous releases of Oracle Designer) and/or files (captured in a third party source control tool or on the file system) to Oracle9i Designer.

## Migration versus upgrade and migration scenarios

The term migration refers not only to the upgrade of the client software and server side software. It also covers the migration of the repository content, populating the repository with files and redesign of the migrated data.

Once your structured elements and files are in Oracle9i Designer (covered in the second part of the migration guide) you can apply five (potentially) different migration scenarios to your Database elements, Developer components (e.g. Forms, Reports, Menus and libraries) and WEB PL/SQL modules.

The migration scenarios listed below are described in detail (e.g. characteristics, steps, when to apply) in Part 3 (migration of database elements), Part 4 (migration of developer components) and Part 5 (migration of WEB PL/SQL modules). Note however that in these parts a specific scenario may be skipped because of its complexity and/or non-applicability.

### Scenario 1. Migrate, Regenerate All, No Redesign

In this scenario, you regenerate your entire application from Oracle9i Designer, including all database elements (e.g. tables, views, PL/SQL definitions), Developer components (e.g. forms, libraries, menus, reports) and WEB PL/SQL definitions.

### Scenario 2. Migrate, Regenerate All, With Redesign

In this scenario, you regenerate your entire application from Oracle9i Designer, including all database elements (e.g. tables, views, PL/SQL definitions), Developer components (e.g. forms, libraries, menus, reports) and WEB PL/SQL definitions. As you regenerate each database element and/or module, you make use of new features as appropriate.

### Scenario 3. Migrate, Regenerate Incrementally

This is the most complex scenario. In this scenario, you migrate your application a little at a time, rather than all at once. You begin by upgrading your database elements in the context of an Oracle9i database (basically do they compile against an Oracle9i database?) then upgrading all of your forms, libraries, menus, libraries, etc. to Oracle9i Developer at the client. You will then make the changes required to run forms, menus, etc. and database elements generated from your previous release of Designer, alongside forms, menus, libraries, etc. and database elements generated from Oracle9i Designer.

### Scenario 4. Migration only of developer components and database components

The first three scenarios all eventually require you to regenerate your application. Any post-generation modifications are lost. If you heavily modified your application post-generation you might consider upgrading the runtime environment to Forms 9i, upgrading your database elements to Oracle9i, and not upgrading both types to Oracle9i Designer. This implies that all future maintenance has to be done manually in Developer. You could however use Oracle Repository as your file source control tool by uploading all sources (including the generated WEB PL/SQL code) into Oracle Repository.

### Scenario 5. Design Capture of database elements and developer components

If you heavily modified your application post-generation, and you would like to adopt (again) a 100% generation strategy, you may want to consider using the Design Capture features of Oracle9i Designer.

## Usage and benefits of a pilot migration

The introduction and usage of a (migrated) Oracle9i Designer repository will have significant effects on the working method and writing method of the Oracle Designer repository participants. New configuration management roles will be introduced and/or the task set of existing configuration management roles will change significantly. Therefore you should consider organizing an Oracle9i Designer pilot project for the following reasons:

- Determination and verification of a migration strategy for migrating to the Oracle9i Designer repository and an investigation of the need for (additional) migration utilities
- Preparation of the participants for the new configuration management concepts
- Creation of a preliminary set of configuration management standards and guidelines
- Determination of the database and hardware requirements of a database instance that will capture your Oracle9i repository.

# Chapter 2 What has changed in Designer?

This chapter describes enhancements found in Oracle9i Designer.

## Storage of structured elements

A structured element is an element whose internal structure (secondary elements, references and properties) is fully known to and understood by the repository infrastructure. The main categories of Structured Element Types at this moment are the Oracle Designer element types (Entity, Business Function, Table Definition, etc.). In addition, Oracle Repository has a small set of core element types of its own, such as Folder and Configuration.

Each Element has properties. Properties can be optional or mandatory, system maintained or fixed or updatable, free text or bound by value domains. The properties come in three categories:

- singular values of data type Number, Date or Varchar2 with a fixed maximum length
- multi line text fields with no fixed length
- references to other objects

Most properties are specific to an element type. A small set of properties is generic: Name, Type, Version Label, Audit properties and IRID. The IRID replaces the ID known from earlier releases. The IRID identifies the Object, not just within its originating repository, but globally. The algorithm that derives the IRID (the SYS_GUID function in Oracle 8) returns a value that is guaranteed not to be produced again, in any repository. You can probably see the benefits this has for migrating data between repositories.

## Storage of unstructured elements or files

All elements that have a structure that is unknown to the repository infrastructure is, somewhat strongly, labeled Unstructured Element. Note that this term does not claim such elements are in fact without internal structure, it merely states that the repository is unaware of that structure and therefore can only handle the element as a whole. Note that even though the Dependency Parsers know enough about the structure of files such as FMB, RDF, OLB, PL/SQL or Java to extract the dependency details, inside the repository these files are for the rest still managed as singular, unstructured objects.

The ability to store Unstructured Elements or Files in the repository is one of the major changes in the repository architecture. It is a change that will alter the role of the repository significantly. From now on all project deliverables and system elements can be stored and managed inside the repository! All Run Time Objects (executables), Sources, Meta-Sources (Templates, Designs, Models, Workshop Notes, User Interviews) and Supporting Objects (Test plans, Project Plan, Standards and Guidelines), whether they are structured or unstructured, can all be made part of the repository. And it is our strong recommendation that they all indeed are stored and managed in the repository.

Files are stored as C(haracter) or B(inary) LOB (Large Binary Object) in the table I$SDD_FILES. Files are created and updated through Uploading from any file system and can be extracted to any file system using the Download operation. Upload and Download can be performed on single files, groups of files or entire nested directory structures, from the RON or the Command Line Tool (on Windows NT). You may Open a file by double clicking it in the RON. Based on the link defined in the Windows Explorer (View, Options, Registered File Types) and stored in the User Profile in the Windows Registry, the indicated tool is used to open (view, edit or run) the indicated file. This allows every user to use his or her favorite editor for opening files from the repository.

Files can be stored in compressed format. The compression and decompression is handled automatically by the repository on upload and download respectively. The compression algorithm is very fast and helps reduce storage space required for files to 2-10%. In the Repository File Registry is recorded which file types (by extension) should be stored as Text (CLOB), Binary format (BLOB) or in compressed format (always Binary). Note that Compare is available for Text Files and the binary files that are produced by Oracle Developer, such as FMB, PLL, OLB and RDF.

## Workareas

A workarea is a user's view of the repository objects on which he or she is working. Within a workarea, repository data is further broken down into application systems and folders, which are known as containers.

In previous releases the systems modeling tools presented repository data in the context of a single application system. In Oracle9i Designer, repository data is presented in the context of a workarea, enabling multiple application systems and folders to be accessed from each tool.

From the familiar Navigator window, you now interact with the repository through a workarea, which is your own particular view of the repository contents. If you create a workarea, you are the owner of that workarea, though you can assign other users access rights to it. You must have access to at least one workarea before being able to do any work in the repository.

Other repository users may make changes to objects that are visible in your workarea. These changes are not immediately apparent to you in the Navigator window, so a workarea refresh mechanism is provided to bring the display up to date with the latest changes. You can preview the effect on the Navigator window display of refreshing a particular workarea, by listing the objects visible in the workarea that have been created, changed or deleted since the last refresh.

The contents of a workarea are initially defined automatically by the application of rules. However, you can manually override these rules and explicitly include any repository object in the workarea, or exclude any object that is already there.

## Containers

You now create a repository object in the context of a container, a logical subdivision of the repository. Two types of container are supported in this release: application system (similar to that available in previous releases) and folder (similar to a directory in a disk-based file system). A repository object is created as a child object of its parent, or owning, container.

## Version control

### Overview

A completely new system of version control of individual repository objects replaces the existing application system level versioning available in previous releases. A checkout/checkin mechanism ensures that different users do not overwrite each other's changes. Graphical tools are available to display the version history of an object, to display object version details, and to display details of various version control events that have taken place for an object.

A branching mechanism permits the development of multiple versions of a product simultaneously using the same set of source files. Branches can be labeled for ease of identification.

Objects can be checked out with a lock, in which case no other user can perform a locked checkout of any versions of the object on that particular branch. Other users can still check out unlocked versions of the object on that branch, but they cannot check them back in on that branch until the original user has released the lock.

Objects can also be checked out unlocked, permitting other users to check out any version of that object without a lock. In this situation, the first user to check the object back in is permitted to do so, whereas subsequent checkins of the object must be merged with the latest version on that branch.

This release provides you with the ability to version and label your designs, for improved change control and multi user access.

Version control is the process of maintaining multiple versions of software development objects and is the most basic requirement for a software configuration management system.

Both repository and non-repository objects can be version-controlled in the common repository.

The repository manages all repository objects, as well as file system files and directories. This enables the tracking of changes to the organization of the source data, as well as tracking the changes to the contents of individual files.

Versions are organized into a version tree structure with branches. Branches have user-defined labels, typically chosen to indicate their role in the development process. All objects can be identified by a system-generated version number. Important versions can be assigned version labels by the user to indicate development milestones.

### Version history

Each object in the repository is held as a set of snapshots (called object versions) of its state at certain points in time. The object versions are linked together by associations that record how each object version evolved from its predecessors. This web of associations, represented by the version tree, is called the version history of the object and can show succession, branching and merging.

The version history associations also have a number of version control attributes, including:

- a unique version identifier
- the identifier of the user who created the object
- the date and time the object was created
- the identifier of the user who changed the object
- the date and time the object was changed
- status of the object (for example checked out or checked in)
- a comment (a descriptive reason for checking in or checking out)

### Checkin and checkout

Version control starts when an object is checked in. Objects that are checked in are write protected. The object must be checked out before it can be modified.

The checkin and checkout process is initiated from the Repository Object Navigator, or from the Version History Viewer utility or from the command line interface.

Only one version of an object can be included in a workarea and only one version of an object is visible through the workarea view. However, the complete history of an object and all the events that occurred to it can be viewed through tools provided by the repository.

Any file or folder in your file system, as well as repository objects, can be the subject of version control. You can copy files and folders into the repository and copy them back to the file system. You can also synchronize your file system with the repository at any time to ensure both are consistent.

When checking an object in or out you can provide notes to briefly describe the reason for the action.

Once the object is checked out, a copy of the object is moved into your workarea. Your workarea contains all the checked out objects you are working with. When the object is checked out, the workarea is refreshed so that the new object version appears in your version resolved view and can be edited by you.

You can undo a checkout but any changes you have made to the object are lost. The system administrator has the privilege to cancel a checkout.

### Branching

When checking in an object, you can decide if the changes are to be included in the branch from where the object was checked out, or if the changes are to be represented on a new branch. Branch labels can provide some meaning to the development strand, for example, as a set of changes related to bug fixes.

Many of the checkin options are available by default. For example the default action could be to create a new branch, with a specified label. This default would apply to all objects checked in from your workarea. This could enable all the changes made on a given set of objects to be queried from the repository and used in release management or quality assurance procedures.

### Locking, comparing and merging

During the checkout operation, the object can be locked so that no other users can check out a copy for editing. If you choose not to lock the object, there is the possibility that when the time comes to check the object back in, another user may have made changes in the interval. In these circumstances, and depending on who checks their version in again first, the compare and merge tools have to be used to ascertain how to check the object back in.

The repository currently supports comparing and merging of three object types:

- structured objects (standard repository objects)
- Oracle forms
- text files

However, it is possible that your organization has added support for additional types.

### Version control tools

The following version control tools are provided:

- Version History Viewer. Illustrates the version history for a chosen repository object in diagrammatic form and allows you to perform version operations such as compare and merge.
- Version Event Viewer. Provides detailed information about the check in and check out version operations that have been performed for a chosen repository object. The information is provided in dialog box format.

The version control tools enable you to perform a number of tasks on both repository objects and file system objects. These include:

- checking in and checking out objects to create new object versions
- viewing the history of an object
- viewing the events that occurred to an object
- creating new version branches
- comparing object versions
- merging object versions
- mapping file systems to the repository
- viewing object version details

The Version History Viewer and the Version Event Viewer are available from the Repository Object Navigator and can also be used as standalone tools.

## Configurations

A configuration is a collection of repository object versions that are related in some way that is significant to an application. Usually a configuration represents all the object versions for a checkpoint in development or component of an application, for example, all the object versions that make up a payroll application, or a screen form used in that application.

Any set of specific object versions can be recorded as a configuration, rather like striping or labeling in some configuration management systems. A specific object version that is included in a configuration is said to be a member of that configuration.

For example, when the development of individual objects reaches the stage where you can build a particular application, you need to specify exactly which version of each object is to be used for the build. The same applies when assembling a set of objects to be used for a test or included in a patch release - the configuration defines which versions of which objects are to be used.

Oracle9i Designer provides a configuration wizard (a predefined set of screen forms) that takes you through the creation process step by step.

The configuration wizard allows you to create a new configuration (or a new version of an existing configuration) containing, for example, all the latest object versions.

An object version that is included in a configuration is referred to as a member of that configuration. Members can be added or removed as and when required. However, only checked in objects can be included in a configuration. Each configuration is a repository object in itself, and can therefore be versioned.

To create a new configuration using the wizard, you start by entering the configuration name and description.

You can base the configuration on:

- a template file containing rules and configurations
- the contents of a workarea
- the latest versions of objects on a specific branch.

You can also create a custom configuration.

You then add, remove or change the version of members as required.

If you choose to base the configuration on a template file, workarea or latest versions on a branch, you may then refine it by adding or removing members or changing the versions of members. You can also add or remove selected rules and configurations.

When you create a new version of an existing configuration you have all the features that are available when creating a new configuration. In addition, you can simply refresh all existing members with the latest versions or refine the existing configuration as required.

All external references are displayed, and you can include externally referenced object versions into your configuration.

When you have completed your new configuration or new configuration version you can either save the configuration only, or save it and check it in to version control. You can add checkin notes and specify a checkin branch.

If you choose only to save the configuration you can edit it later without creating a new version.

## Folder and file synchronization

When you upload a file, the system copies the file from the file system to the repository. Both copies can be opened and edited independently, and this could lead to differences between the two copies of the same file.

Some means is necessary of ensuring that the two copies are kept up to date with each other. Oracle Repository provides a synchronization mechanism that enables you to keep the repository copy up to date with the file system copy or vice versa.

When you perform synchronization, the system checks whether any changes have been made to the repository copy, the file system copy, or both.

The resulting actions are:

Repository copy | Repository copy | File system copy | System Action
--- | --- | --- | ---
Unchanged |  | Unchanged | None
Unchanged | Checked in | Changed | Displays dialog for user intervention
Unchanged | Checked out | Changed | Uploads copy from file system
Changed |  | Unchanged | Downloads copy to file system
Changed | Checked in | Changed | Displays dialog for user intervention
Changed | Checked out | Changed | Displays dialog for user intervention

Files where the file system copy has been changed while the repository copy remained checked in are known as "hijacked files". For these and other cases where a dialog is displayed for user intervention, you can choose to upload the file system copy, download the repository copy, check the repository copy in or out and resynchronize, or merge the two copies, resolving the differences one by one.

A few special cases are worth noting:

- If you change the repository copy and subsequently delete the file system copy before saving the changes, those changes are lost.
- If you delete the repository copy but not the file system copy before synchronization, the repository copy will reappear on synchronization. This is because in this case it is treated as a new file and uploaded accordingly. The same applies if you exclude the repository copy from your workarea.
- If you delete the repository copy but not the file system copy after the two have been synchronized, subsequent synchronization operations offer you the choice of deleting or retaining the file system copy. The same applies if you exclude the repository copy from your workarea.

## System privileges

Repository owners and subordinate users need system privileges to use the repository. For example:

- a repository owner needs system privileges to install a new repository
- a subordinate user needs system privileges to create database objects.

You use the Check Requirements tool on the Repository Administration Utility to assign system privileges.

Note: Only the Oracle database administrator can assign system privileges.

## Access rights

The functionality for repository user maintenance has been greatly extended. The repository owner can now specify whether a particular subordinate user can perform certain repository management operations, such as creation and deletion of workareas, or force delete or purge operations on repository objects. In addition, the repository owner can control a subordinate user's access to individual repository tools, such as the Repository Object Navigator or the Command Line Interface.

## Repository policies

You can set repository-wide options that control certain aspects of:

- version control
- file naming (case sensitivity)
- object dependencies

### Version control policies

A user with the Set Policy system privilege can impose restrictions on the following versioning features:

- branching
- version labeling
- locking

By setting policies you can ensure that specific development branches are not populated with new object versions at critical periods in development, for example during a build. It also ensures adherence to system-specified object version labels.

### Automatic branching

When an automatic branching policy is set, all checked out objects will check in to the default checkin branch set for each workarea.

If a default checkin branch is not set for a workarea, object versions in that workarea will check in to the branch they were checked out from.

### Automatic version labeling

When automatic version labeling is set, the user is unable to specify a label for an object version on checkin. The repository will automatically assign a label.

### Strict locking

When strict locking policy is applied, users are forced to lock objects on checkout. Because two or more users cannot apply locking to object versions on the same branch, a strict locking policy prevents concurrent development of object versions on the same branch.

Without a strict locking policy in force, a user can choose whether or not to lock an object on checkout. In this situation, locking does not prevent another user from checking out an unlocked copy of the same version. It only prevents that user from checking in on the same branch until the locked version is checked in.

### File naming policy

The case sensitive uniqueness policy ensures that case sensitivity is applied to the names of file system files and their containers when these are created in the repository. When the policy is in force, for example, you are able to create a file named "MyFile" and a different one named "myfile". When the policy is inactive, these two files would be treated as the same file, so creation of the second one would not be allowed.

This policy is of particular use for files that are uploaded from a UNIX server, where case sensitivity is a feature of file and directory names.

### Dependency policies

Further options control whether object dependencies are copied by default when a repository object is either versioned or copied. In either case the default can be overridden at the time of the operation.

## Short cuts versus shares

Shares as we know them in Oracle Designer 6.0 and before no longer exist. You are allowed to create references to elements anywhere in the repository, provided these elements are owned by folders that you have select privileges on. You do not need to create a share to the context folder. In the figure below Column Job in Table Definition HRM/DESIGN/HSD_EMPLOYEES has a reference to a domain JOB TITLES that is owned by Folder CORPORATE. This reference is created without sharing the domain to the HRM/DESIGN Folder. For those amongst you who suffered from dummy and skeleton application systems: they are a thing of the past! Moving an element from one folder to another will not create shares for referenced objects, as was the case for the transfer operation in Oracle Designer 6.0.

The following shows that no share is required in order to have a reference to a domain in a different folder:

A valid question now would be: does this mean we do not have shares at all anymore? The answer is: well, no, but we do have something very similar. And to overcome any ill feelings you may harbor against shares, this new mechanism is called short cut. It is indeed very much like the File System Short Cut you may know from MS Windows. And it offers some nifty features.

A short cut is a link between a Folder and an Element, with the ownership flag set to false. Short cuts are created by dragging and dropping the element to the Folder (or Edit, Copy; Edit, Paste Reference). Select privileges are required on the owning Folder and Update privileges on the target Folder. Links between a Folder and an Element with the ownership flag set to true indicate the Owning Folder link. Note that you cannot create a short cut for a Folder, only for individual Elements. Also note that a short cut applies to all versions of the element it is created for. Creating a short cut from Folder HRM/PUBLIC to Table Definition HSD_DEPARTMENTS means: linking every single version of HSD_DEPARTMENTS to HRM/PUBLIC.

In the context of a Folder, you will see all its owned Elements as well as its short cuts. That means that you can see and reference elements without having to search and navigate through the entire repository. Furthermore, if you click on the little hand icon or press F12, you will navigate directly to the source of the shortcut. New (compared to shares in Oracle Designer 6.0) is the ability to edit-in-situ: if you have update privileges on the Folder that owns the Element, you can directly update the Element short cut without having to navigate to the owning Folder. Another step forward is the ability to copy a short cut. That means: you can drag & drop a short cut to a Folder, thus creating a short cut to the same Element that the original short cut links to.

# Chapter 3 A version enabled repository versus a non-versioned repository

You should realize that you can still use Oracle9i Designer as you always have before, i.e. use Oracle9i Designer as your repository for non-versioned structured elements only. In time you may consider the storage of files as well and finally enable the versioning of both element types. This chapter will provide you with an insight on how to use Oracle9i Designer, and it provides an overview of the relevant chapters of Part 2 "Migrating the repository" for each Oracle9i Designer mode.

## Unversioned structured elements

If you do not want to version your elements - the reasoning on which to base your decision will be provided soon - you simply should not enable the version option in the Repository Administration Utility just after a fresh Oracle9i Designer installation. As long as the version option is not enabled you can store only "one version" of each element, just like in previous Oracle Designer releases. In fact the version properties of each element will not be populated, because you will never be able to check in an object. You will only commit your changes. Each participant will use the GLOBAL_SHARED_WORKAREA.

In addition you should instruct your participants not to store any file in the repository. Note that there is no system repository option available that can stop you from populating the repository with files.

You will typically use Oracle9i Designer in this specific mode in the following circumstances:

- The size of your project is quite small (e.g. less than 10 participants)
- You have not yet reached the test phase. You are still in the strategy, analysis, design or build phase. You do not need some kind of parallelism.
- The number of files to manage are limited (e.g. less than 30)
- You still want to use your third party source tool to manage your files

The following chapters of Part 2 "Migrating the repository" are relevant:

- Chapter 1 "Introduction"
- Chapter 3 "Migrate structured data"
- Chapter 7 "Migrate users and assign access privileges"
- Chapter 9 "A typical migration plan"

Obviously you may skip all sections in the above chapters that handle the versioning of data.

## Unversioned structured elements with unversioned folder/file support

If you do not want to enter the versioned world, but you do want to store files in addition to structured elements, you also simply should not enable the version option in the Repository Administration Utility.

In addition you should provide your participants with guidelines on how to store files and folders in the repository. More specifically you should set up a folder hierarchy with appropriate access rights. See also Chapter 7 and Chapter 8 of Part 2.

You will typically use Oracle9i Designer in this specific mode - thus including the storage of unversioned files - in the following circumstances:

- The size of your project is quite small (e.g. less than 10 participants)
- You have not yet reached the test phase. You are still in the strategy, analysis, design or build phase. You do not need some kind of parallelism
- The number of files to manage are substantial (e.g. more than 30)
- You want to adopt a single repository approach and therefore you no longer want to use your third party source tool to manage your files

The following chapters of Part 2 "Migrating the repository" are relevant:

- Chapter 1 "Introduction"
- Chapter 3 "Migrate structured data"
- Chapter 4 "Migrate files from third party source control tools" or Chapter 5 "Migrate files that are stored on the file system"
- Chapter 7 "Migrate users and assign access privileges"
- Chapter 8 "Synchronize the file system and the database with the repository content" (specially the file system synchronization)
- Chapter 9 "A typical migration plan"

Obviously you may skip all sections of the above chapters concerned with the versioning of data.

## Versioned structured elements with versioned folder/file support

If you would like to enter the versioned world, you simply enable the version option in the Repository Administration Utility just after a fresh installation and you provide at least some users with the container access right "version". See also Part 2, Chapter 7 "Migrate users and assign access rights".

You are likely to want to enter the versioned world for at least the following reasons:

- Your application is already in production, you have to maintain it and at the same time you would like to add new functionality and/or change existing functionality
- You want to improve the quality of your deployment process by using a variety of impact analysis tools
- You have to develop and support multiple releases for multiple customers
- You have to develop your application in multiple languages
- You have to support some other kind of parallelism
- Developers are losing work because they are frequently overwriting each other's sources. In other words there is a real need for workspace procedures.
- You want to keep intermediate copies or versions of specific elements in the context of prototyping.

Your migration efforts are more substantial. The following chapters of Part 2 "Migrating the repository" are relevant:

- Chapter 1 "Introduction"
- Chapter 3 "Migrate structured data"
- Chapter 4 "Migrate files from third party source control tools" or Chapter 5 "Migrate files that are stored on the file system"
- Chapter 6 "Reorganize a migrated Oracle9i Designer repository"
- Chapter 7 "Migrate users and assign access privileges"
- Chapter 8 "Synchronize the file system and the database with the repository content"
- Chapter 9 "A typical migration plan"

Prev | Next
| Copyright © 2002, Oracle Corporation. All Rights Reserved. |
Contents