Guidelines for Data Fixes

Guidelines for database components of migration:

For release with data model changes:

DBA will not make any changes to any table without a physical data model review.

DBA will not make any changes to any table without the approval from the DAs. The DA who reviewed the data model changes should be copied of the release request.

CREATE TABLE statements should be submitted for new tables or changes to existing tables. A description of what the changes are should be included in the documentation.

Data conversion scripts should be in normal SQL commands that can be executed from SQL*Plus. PL/SQL scripts or any other scripts may be accepted in a case by case basis but it will slow down the migration of the application.

Please review the DDL generated by Oracle Designer before submitting migration request. Normal errors are a) columns are not in the order approved by DA; b) useless indices, such as indices on foreign key referencing code tables with 3 or 4 values only, are included; c) table with a sequence value as its primary constraint does not have a unique constraint; d)missing unique index on the business primary constraint column(s).

For new applications or major rewrites, please submit changes to the data model as soon as it has been approved by the DA. Executables can be submitted in subsequent releases. Depending on the complexity, it might take weeks to get the model changes into the database.

For releases with no data model changes:

All executables such as functions, types, packages, triggers, procedures, views must be included in each release regardless whether the objects are being changed or not. This allows for easy re-deployment or rollback of the executables.

Unless special arrangement is made with the DBA, all objects will belong to the schema ‘THE’, however, no direct reference should be made by the application to the schema owner – ie. Application code should be schema independent. All objects (tables included) should be referenced through public synonyms.

All functions, packages and procedures should begin with

CREATE OR REPLACE

You cannot use CREATE OR REPLACE for types. You should include a script to drop types and specify that in your documentation.

Please make sure that all executables can be compiled from SQL*Plus without syntax errors. DBA will not make any corrective changes to the script submitted regardless how trivial the changes are.

All application stored procedures, functions, packages, and types must be prefixed with the application acronym of the owning application. Any exceptions to this rule must be approved by DBA before submitting the migration request.

Note: In addition to this, no SIL* objects will be accepted anymore. These shared application objects will be phased out, to be replaced by individual application objects.

Other related information:

All releases should include a security matrix spreadsheet. Please see guidelines for security matrix for details.

If you are creating new security roles, you must consult with Websupport.

Code tables will be created empty. Please do not submit scripts to populate code tables, instead, contact your DA and request for entries to be added to application code tables.

Releases to test will be handled on a first come first served basis, once Change Management has approved the release. For releases with model changes, it is not deemed to be in our hands until the DA approves the changes. All effort will be made to complete the release within 5 working days once validated by the DA Group. Please allow the DBA this window before checking the status of the release.

The application custodian must contact the DBA for any production release after the release request is submitted. Release must be submitted at least 2 working days before they will be processed. All production releases are to be processed during normal working hours. Please notify your user on our start time. We do not and will not provide an ETA as experience tell us that we will almost always be wrong on the estimate.