Oracle SCM Release Notes |
If you print out this document, we recommend that you use landscape page format, so that long lines of text (such as command line inputs) are not truncated.
Certification against Oracle9i
Upgrade from Oracle Designer Release 1.3.2
SCM Install Guide references to Release 4.1
Oracle SCM is certified against Oracle 8.1.7 and Oracle9i. For Oracle9i, if patch set 9.0.1.3 is not available, then 9.0.1.2 can be used provided the following one off patches are applied, taking care to download the patch specific to your particular platform:
The earliest previous release from which Oracle SCM provides upgrade is Oracle Repository 6.0. Users of the older Oracle Designer Release 1.3.2 wishing to upgrade to Oracle SCM will therefore need to upgrade to Oracle Designer 6.0 first. The following alternatives exist for locating the upgrade to Oracle Designer 6.0:
When installing Oracle SCM, a combination of different product languages can be selected for installation on the same machine. If Japanese is selected as one of these languages (for example: a selection of Japanese, Korean and English) then users should be aware that the user interface (translations) will be in Japanese and this cannot be altered by changing the NLS language on the client machine. If Japanese is not selected as one of the product languages (for example: a selection of Chinese, Korean and English) then the user interface will be in English. Therefore, if users do not require the user interface to be in Japanese, then Japanese should not be selected as one of the product languages. If Japanese is selected as one of the product languages, users should check that a Japanese font has been installed.
Note that any references in the SCM Install Guide to SCM Release 4.1, in connection with upgrade, also apply to SCM Release 4.1.1.
This section documents known problems and restrictions for:
Problem:
PL/SQL definitions will be migrated incorrectly if you migrate Designer 6.0
data to a Designer 9i repository on Oracle9i Standard Edition. No error
message will be displayed but, after migration, any text in the 'PL/SQL Block'
property of a PL/SQL Definition will have been moved into its 'Private Declaration'
property
Workaround:
There are two possible workarounds:
Problem:
Unable to invoke a SCM java tool when connected to a repository on an Oracle9i
server. This problem can be encountered when trying to invoke any of the SCM
java tools, which are:
The failure to invoke a java tool may occur in the following ways:
1 |
Problem: Java application does not invoke |
2 |
Problem: [JDK2] No message error at ...RepositoryConnection.setConnection(RepositoryConnection.java:608) |
3 | Problem: java.lang.IllegalArgumentException : ErrorDialog:
null message vector This occurs when running the Dependency Manager (ckdm61) from the DOS command prompt |
4 | Problem: CDR-03120 : Internal Error - Problem making a Repository
Connection This occurs when invoking the VHV, VEV or Compare Utility from the Repository Object Navigator |
5 | Problem: Connect dialog keeps appearing This occurs when invoking the Dependency Manager from the Repository Object Navigator or the Oracle Designer Front Panel |
All of these problems stem from the same cause. The 9i JDBC connection appears to be sensitive to the precise format used for the TNSNAMES.ORA entry. Entries which work for SQL*Plus and the SCM C++ tools do not work for the thin JDBC connection required by the java tools when connecting to an Oracle9i server.
Note that:
Workaround:
In order to be able to invoke a SCM java tool, ensure that the entries for Oracle9i
servers in your TNSNAMES.ORA are of the following form :
alias.names.default_domain = (DESCRIPTION =
(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = host.domain) (Port = 1521))) (CONNECT_DATA = (SERVICE_NAME = SID)) )
Specifically, ensure that::
Problem:
During migration, the stage CKREPINI may fail with the following error:
end-of-file-communication channel ORA-24323: value not allowed Error accessing package DBMS_APPLICATION_INFO ORA-03114: not connect to ORACLEWorkaround:
Problem:
When attempting to install Oracle SCM on an Oracle 8.1.7 database, the
following error can be encountered.
CDR-21244 This process has been aborted. The previous process has failed or the user has aborted it.
This problem occurs because Oracle9i import and export utilities are not compatible with an Oracle 8.1.7 database. This not a bug but an Oracle9i design feature.
Workaround:
To install Oracle SCM on an Oracle 8.1.7 database, you will first need to install
Oracle 8.1.7 import and export utilities in a separate Oracle Home. The registry
variables EXECUTE_IMPORT and EXECUTE_EXPORT need to be changed to point to these
8.1.7 import and export utilities instead of to the Oracle9i versions. These
variables are found under the key:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\REPOS61
Note that when installing the 8.1.7 import and export utilities, the following error may be encountered:
There is no oracle.swd.jre 1.1.8.10
The workaround here is to use the Oracle Universal Installer installed onto your hard disk with the Oracle9i install, to install the Oracle 8.1.7 components.
Problem:
Upgrade to Oracle SCM from a release of Oracle Repository 6i earlier
than 4.1 or 4.1.1 does not reload the package and package body for JR_RULE_PROCS.
After upgrade, if you try to create a workarea specifying a LATEST_DIAGRAM_CONTENTS
rule in the Repository Object Navigator or the Command Line Tool, the following
error may be encountered:
CDR-01005: Workarea compilation failed: Error executing rule. CDR-00108: Error occurred whilst executing rule LATEST_DIAGRAM_CONTENTS(apsys1{1.2}/ERD001{1.0}=Diagram,MAIN) ORA-06550: line 1, column 41:
PLS-00302: component 'LATEST_DIAGRAM_CONTENTS' must be declared
ORA-06550: line 1, column 7: PL/SQL: Statement ignored
Workaround:
The JR_RULE_PROCS package and package body need to be reloaded through the Repository
Administration Utility. In the RAU, select the 'View Objects' option. Select
PACKAGE JR_RULE_PROCS and mark for reload.Select PACKAGE BODY JR_RULE_PROCS
and mark for reload. Exit the 'View Objects' utility, and click on Yes when
prompted to reload specified objects.
Problem:
In previous releases of the Repository Administration Utility, subordinate users
were able to perform migration as well as the repository owner. This has now
been changed so that, by default, only the repository owner can run the Migration
utility. However, some sites may still wish to allow subordinate users to perform
migration.
Workaround:
In the Repository Administration Utility, the repository owner can explicitly
grant a subordinate user access to the Migration utility by enabling the "Migration
Utility (RAU)" checkbox on the Repository User Properties dialog for that
user.
Problem:
In the Repository Administration Utility, no reminder is displayed about performing
a full reconcile after remapping an existing user-extended element type.
Workaround:
Always perform a full reconcile after remapping a user-extended element type.
Problem:
In the Repository Administration Utility, if you select the Remove Repository
option, the process fails to drop Oracle types created as part of the repository
installation. The message:
ORA-02303: cannot drop or replace a type with type or table dependents
is displayed, followed by the message:
RME-02124: Failed to execute SQL statement: drop TYPE type_name
This error occurs because export tables that are dependent on these types are still present in the schema of the repository owner or a subordinate user.
Workaround:
Drop all export tables in the repository owner's schema and the schemas of
all subordinate users (the names of export tables have either the XT_ or the
XTSYS_ prefix). Having done this, retry the Remove Repository operation.
If using only files and folders, you might want to turn off the heading "Files" in the Navigator window. To do so, choose Navigator > Show Hide, select Objects in the Show Type Headings field and select the Never option button.
To check in the contents of a workarea or container, choose Version > List Checkouts, select the sub-context and click OK. In the List Checkouts dialog box, click Select All, then click Check In.
Note that if you purge versions from a workarea, prior versions, or other versions depending on the appropriate workarea compilation rule, will not appear until the workarea is refreshed.
The Compare and Merge utilities, and the Version History Viewer and Version Event Viewer are written in Java. The first time one of these tools is invoked, a Java Virtual Machine (JVM) is started within the Repository Object Navigator process. It will then appear that the Navigator is using a great deal more memory. The JVM is not shut down until the process ends, so this memory usage will not decrease until the Repository Object Navigator is shut down, even though the tool window may have been closed.
The memory parameters used by the JVM at startup can be controlled by registry settings. Memory allocations may need to be increased or adjusted depending on usage and the host environment. You can do this by changing the values of the following Windows registry variables, all of which are shown in bytes under the following registry keys
Key HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn\REPADM61
JVM_NATIVE_STACK_SIZE
JVM_JAVA_STACK_SIZE
Key HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn\REPADM61\DEFAULT_JVM_PARAMS_THIN_JDBC
JVM_MIN_HEAP_SIZE
JVM_MAX_HEAP_SIZE
(where HOMEn is home number of the home installed into for a multiple
Oracle home environment, but is not present where the default Oracle home is
being used):
There is also a problem in that the memory used by each invocation of one of these Java tools is not completely freed up. This may result in out-of-memory conditions arising after many invocations. If this happens, shut down and restart the Repository Object Navigator, or invoke the utilities from the Command Line Tool, which runs in its own JVM.
Problem:
In the Repository Object Navigator, the default rule in the file registry
is Text File for files with .DOC or .doc extensions, but on Win32 systems
these extensions are most likely to be used for MS Word files, which are binary.
Workaround:
From the Utilities menu, choose Edit File Registry and use the Edit Rule option
to change the rule to Binary File for files with these extensions.
Problem
This problem affects users running against an 8.1.7 server on OS/390 using
EBCDIC character set. The error "ORA-1722: invalid number"
is encountered when creating a new workarea via the front panel, or on opening
a newly created workarea. Although it is possible to dismiss the error
and continue, the workarea is shown without a name in the Repository Object
Navigator. Also, if you create an application system in this workarea,
and close the Repository Object Navigator and re-open it, the name of the
application system will not be displayed in the navigator tree.
Workaround
A possible, but not entirely satisfactory, workaround is to replace the shipped
version of ORA805.DLL with an earlier version. The shipped version of
ORA805.DLL in Oracle Repository 6i Release 4.1.1 is 8.0.6.0.0, and the problem
will disappear if this is replaced by ORA805.DLL version 8.0.5.0.0. However,
this earlier version still contains bugs that will prevent the Repository Administration
Utility from operating correctly. ORA805.DLL can be found in the bin directory
of your Oracle home.
Problem
If you are using the Repository Object Navigator and are connected to a repository
on the default database of the local machine (i.e. connected as repos/manager
with no connect identifier specified), you will not be able to invoke the
VHV, VEV, Dependency Manager and Compare utilities. The following error
will be displayed:
CDR-03120 : Internal Error - Problem making a repository connection.
The Command Line Tool will invoke and immediately close down. If you
invoke the Command Line Tool directly and try to connect to a repository on
the default database of the local machine you will get a Java error.
Workaround
Connect to the repository on the default database of the local machine by
specifying a Net8 alias e.g. repos/manager@local, where local
has been set up as an alias or Net8 connect identifier for the local database
by Net8 Configuration.
Problem:
In the Repository Object Navigator, the import of an application system may
fail with an error indicating that conflicts have been detected between user
extensions exported from the source repository and the target repository,
and that these must be resolved before import can proceed.
Workaround:
Using the Repository Administration Utility, extract the user extension definitions
from the source repository and load them into the target repository. The import
of the application system in the Repository Object Navigator should now work.
Problem:
When invoking the VHV for a configuration in the Repository Object Navigator,
the dialog 'Set Context Workarea' may be displayed and the Repository Object
Navigator hangs.
Workaround:
Before invoking the VHV for a configuration, invoke the VHV for any other object
and then close it. Now, invoking the VHV for a configuration will work.
An alternative workaround is to use the Command Line Tool instead of the Repository Object Navigator to invoke the VHV for the configuration. The Command Line Tool will prompt the user to set the workarea context but, once this has been done, the VHV for the configuration will be successfully invoked.
Problem:
After invoking the Repository Object Navigator and navigating to a versioned
object (eg 'SYSTEM FOLDER'), the following error may be encountered when invoking
the Version History Viewer, the Version Event Viewer, Merge or the Compare utility:
CDR-17060: Failed to load class oracle/repos/rs/rsj/CRSjlnProcDispatch
and, if you try again, a different error may be encountered:
CDR-17057: Failed to initiate JVM
This problem is caused by the classpath exceeding 1000 characters and will only occur when invoking these tools from the Repository Object Navigator.
Workaround:
The simplest workaround is to use the Command Line Tool instead of the Repository
Object Navigator to invoke the required tool such as the Version History Viewer,
and this problem will not occur.
Alternatively, if this workaround is not acceptable because you wish to use the Repository Object Navigator for launching these tools, then ensure the Oracle Home directory path is short. To avoid the classpath exceeding 1000 characters, the path of the Oracle Home directory must be 14 characters or less. For example: an Oracle Home directory path of D:\Ora9i_ids_m would not result in this error being encountered, but one or more further characters in this path, such as D:\Ora9i_ids_m1, would result in this problem.
If the Compare Utility fails to invoke, this may be as a result of a common problem shared by other SCM java tools. The full problem description and workaround can be found at the beginning of this section.
Problem:
When the Compare utility is invoked from the Repository Object Navigator,
a program failure can occur if the Compare window is maximised, the window
divide bar is moved and then the close button (x) at the top right is pressed.
Workaround:
Invoke the Compare utility from the Version History Viewer or the Command
Line Tool and this problem does not occur. Alternatively, if invoked from
the Repository Object Navigator, do not maximize the Compare window.
Problem:
In the Repository Object Navigator or Version History Viewer, an attempt to
compare or merge a generated .FMB file that has already been merged may fail.
Messages from the Repository Object Navigator are:
CDR-03100: Diff/Merge internal error: java.lang.IllegalStateException (compare) CDR-03126: Internal Error - Object Delta retrieval (merge)
The message from the Version History Viewer for either compare or merge is:
java.lang.IllegalStateException
Workaround:
None.
Problem:
The Compare utility cannot compare versions of a subclassed form that are in the same workarea or configuration. In addition, rather than reporting an error, the utility sometimes appears to have successfully compared the versions of the subclassed form.
A warning dialog box (currently undocumented in the online help) is displayed to inform you that that it is not possible to compare in these circumstances. You should ignore this warning when not comparing versions of a subclassed form in the same workarea or configuration.
This warning can be turned off by adding a string value to the registry key:
HKEY_CURRENT_USER\SOFTWARE\ORACLE\REPOS61\FORMSDM
Create a string value "SUBCLASS_WARNING" with value "FALSE". Any other value (or the string not existing) results in the warning being displayed.
Workaround:
Any compare of a subclassed form must be carried out on versions that are in different workareas or configurations.
The Compare utility enables you to compare different versions of the same Oracle Form file, but not two different Forms files. When comparing files other than Oracle Forms, two different files can be compared.
If Merge fails to invoke, this may be as a result of a common problem shared by other SCM java tools. The full problem description and workaround can be found at the beginning of this section.
After making changes, use File->Save to save your changes. (N.B. Earlier versions had a 'Save' button' which did this).
If the Version History Viewer fails to invoke, this may be as a result of a common problem shared by other SCM java tools. The full problem description and workaround can be found at the beginning of this section.
Problem:
Any attempt to perform a merge operation in the Version History Viewer results
in the folowing error
java.lang.IllegalArgumentException : setRoot : Null Filename
and the merge aborts.
Workaround:
Perform the merge using a tool other than the Version History Viewer. For example,
use the Repository Object Navigator.
If the Version Event Viewer fails to invoke, this may be as a result of a common problem shared by other SCM java tools. The full problem description and workaround can be found at the beginning of this section.
Problem:
Running the Version Event Viewer with a start date in which the year is set
to 99 or earlier causes no event data to be displayed in the viewer window.
Workaround:
None.
Workaraound:
When Importing, use the option 'Create new versions where objects exist'. This
will create new versions of any objects which exist in the target repository,
conserving all the data from source repository at the target.
Problem:
When importing a workarea containing versioned objects into the same repository
using the option 'Create new version where objects exist in the destination
repository, otherwise create new objects', the import will fail if you try
and create a new workarea by specifying a new workarea name in the wizard.
Workaround:
Create a new workarea with the relevant name before you run the Import Wizard.
The repository utilities Export and Import in database format are designed to take advantage of the universal uniqueness property of the Repository Object Internal Identifier. For example an object can be copied from one repository to another using Export and Import without having to change its internal identifier.
This feature is used by the Export and Import utilities to allow new versions of objects to be copied to other repositories even though the logical identifier or user's identifier (e.g. NAME) has changed. It also means that object versions can be exported which have references to other objects not included with the export, i.e. an object version may contain dangling references. This is not a problem so long as a) a subsequent export or import copies in the missing referenced objects, or b) the dangling references are resolved, either by deleting that part of the dangling object's structure which includes the reference, or by nullifying the reference property.
You should always precede an export operation with a check for external references within the set of candidate export objects. For example, a workarea or container may include the definition of a module object which references a language object not included in the workarea or container.
To resolve dangling references automatically at the target repository, select the "Remove dangling references" option on the Advanced Options dialog box in the Import Wizard. This option is highly recommended if the Import is creating 'brand new objects' as it will not be possible to copy new versions or related versions later on.
Problem:
Importing into a workarea or refreshing a workarea can fail with the following
error:
CDR-01062: Compilation leaves file filename orphaned. Need to include container
This may have been caused by deletion of a previously imported folder that contained a share of an object, where the original object was not imported and does not exist in the workarea. In this situation, it is the share of the object that is causing this error.
Workaround:
Restore the deleted folder from the Wastebasket. Invoke the Command Line Tool
and re-attach the shared object from the Lost+Found container. The shared object
will now be seen as an original object and can be deleted causing no further
problems
For a versioned repository, depending on the kind of export performed, the Import utility will execute operations on your behalf which may require certain privileges, e.g.:
Manage Workareas - allows user to create a workarea
Compile - allows user to compile or refresh a workarea
Version - allows user to create new versions of objects within a workarea
If an error is returned by any of these operations, check that you have the appropriate repository privileges (assigned via the Repository Administration Utility) and workarea and container access rights (assigned via the Repository Object Navigator).
For a non-versioned repository, none of the above operations apply. The Import Wizard will normally detect this case.
Problem:
When building dependencies for Oracle Forms .fmb files, the following error
may be encountered:
Failed to read global name domain FORMS_GRAPHICS Cause: A global name domain does not exist Action: Create the name domain via the Dependency Manager
Workaround:
Missing global name domains need to be created manually via the Dependency Manager.
Invoke the Dependency Manager, and from the Tools menu select 'Manage User Defined
Global Name Domains ...'. Click 'Add' and enter the following details:
Name: FORMS_GRAPHICS Display Name: Forms Graphics Display Plural Name: Forms Graphics
Click 'OK'. Click 'Add' again, and enter the following details:
Name: FORMS_MODULE_PARAMETER Display Name: Forms Module Parameter Display Plural Name: Forms Module Parameters
Click 'OK'. It should now be possible to build dependencies for the Forms .fmb file.
If the Dependency Manager fails to invoke, this may be as a result of a common problem shared by other SCM java tools. The full problem description and workaround can be found at the beginning of this section.
Problem:
Running a purge from the Dependency Manager fails because of lack of extents
for rollback segment.
Workaround:
Force dependency purge to use suitably sized rollback segment; only one rollback
segment (of sufficient size) needs to be available. You can achieve this by
making all rollback segments offline except for one large rollback segment.
See the Oracle SCM Installation Guide for instructions to do this.
Problem:
The Show Dependencies option in the Dependency Manager could fail because
of container access rights for objects using, or used by, the selected object.
The option can fail with message:
CDR-18019: Failed to load a container
Workaround:
None.
The MATCH_CASE session variable can be used to switch on and off the matching of case for names of objects. Switching the MATCH_CASE session variable off, using a
set match_case off
command, may degrade performance in larger repositories.
If the Command Line Tool fails to invoke, this may be as a result of a common problem shared by other SCM java tools. The full problem description and workaround can be found at the beginning of this section.
Problem:
When attempting to exit from a long running command, CTRL-C not only terminates
the command that is running but also the Command Line Tool. All outstanding
uncommitted changes will be lost.
Workaround:
Do not use CTRL-C unless you want to terminate the command line session completely
and you are not concerned about any changes that have not been committed.
Problem:
Users are unable to import into a new repository.
Workaround:
An export needs to be run first on all new repositories so that certain tables
will be created to allow an import to complete. Once the initial export is
run, the missing tables will be created.
Problem:
The name length limit is 26 characters for primary object table names and
25 characters for secondary object table names. Registration generates objects
and code and appends prefixes and suffixes to table names to generate unique
names. Registration adds up to four characters for primary objects and up
to five characters for secondary objects.
Workaround:
Keep table names less than 26 characters for primary objects, or 25 characters
for secondary objects, or rename the table to a shorter name and create a
synonym for it using the original name. Registration will preserve the synonyms
in the generated schema and thus any application code should continue to work.
Problem:
The generation phase of registration can fail, for example, due to insufficient
privileges.
Workaround:
Drop the schema using 'drop_schema' before running 'generate' again.
Problem:
Registration uses only the first 100 characters of the default value, so it
will corrupt any values longer than this.
Workaround:
Do not use column default values longer than 100 characters.
Problem:
Secondary objects are not copied unless the primary key is the IRID (the repository
object identifier).
Workaround:
Create the IRID as a surrogate primary key on secondary objects.
Problem:
In the Repository Object Navigator, copying elements derived from registered
types fails if they have primary or unique key columns which are not declared
as the 'descriptor' column (or name column, using the name pragma).
Workaround:
Make sure that the only primary or unique key is defined on a single column
which is declared as the 'name' column. Alternatively, use the generated copy
API directly and provide new values for any primary or unique key columns
(note that this can be done only for the primary object and not any of the
secondary objects that it might own).
Problem:
You cannot register schemas with owning foreign keys which are not defined
as cascade delete.
Workaround:
Do not define owning foreign keys which are not defined as being cascade delete.
This will mean that some tables may be defined as primary objects when they
should really be secondary objects (i.e. part of some other object).
Problem:
You cannot register schemas with owning foreign keys that reference unique
keys.
Workaround:
Do not define owning foreign keys that reference unique keys. This will mean
that some tables may be defined as primary objects when they should really
be secondary objects (i.e. part of some other object). Alternatively, create
a surrogate primary key on the owning table and a foreign key on the secondary
table that references this primary key.
Problem:
The generated PL/SQL API cannot be used to manipulate registered objects.
Insert via the API returns the following error:
ORA-06502: PL/SQL: numeric or value error: character to number conversion error
Using the Repository Object Navigator returns the following error:
ORA-01403: no data found
Workaround:
If not using the API this problem does not occur, i.e. SQL inserts and updates
will work correctly. To use the API, the foreign keys will have to be numeric.
Problem:
Cannot reference Designer tables from registered tables.
Workaround:
Use the user extensibility feature in the Repository Administration Utility
to extend the Designer model.
Problem:
Oracle types are not supported.
Workaround:
None.
Problem:
Registration will register new objects from a schema, created since that schema
was last registered, but does not currently support modification of existing
objects.
Workaround:
The registered schema must first be dropped from the repository and then registered
again (when all objects will then be registered from scratch).
Problem:
Registration will register new objects from a schema, created since that schema
was last registered, but does not currently support registration of individual
objects.
Workaround:
None, apart from re-registering entire schema, see previous issue.
The broadcast server does not work on Solaris systems (bug 1325598).
In some circumstances message ORA-12514 is displayed without its intended text.
Intended text of message:
ORA-12514 : TNS:listener could not resolve SERVICE_NAME given in connect descriptor
Cause:
The SERVICE_NAME in the CONNECT_DATA was not found in the listener's tables.
Action:
Check to make sure that the SERVICE_NAME specified is correct.
Comment:
This error will be returned if the database instance has not registered with
the listener; the instance may need to be started.
Problem:
If you create a configuration based on the current contents of a workarea,
the configuration will consist of the entire contents of the workarea, possibly
including objects to which you do not have access.
Workaround:
Either manually remove the inaccessible objects from the configuration (e.g.
Remove Members in the Configuration Wizard) or create the configuration based
on the workarea specification rather than the workarea contents (e.g. use
"from specification" in the Configuration Wizard rather than "from current
contents").
Problem:
Creating or generating tables or views named DUAL to the database will cause
serious problems as the system will access the user-defined DUAL table instead
of the required Oracle Server pseudo table SYS.DUAL. All workareas and containers
disappear, and other unpredictable behavior may also result.
Workaround:
Use a name other than DUAL for the table or view.
Problem:
This applies when building a workarea based only on a configuration and with
no check-in branch specified. If you use the workarea to check out and check
in an object, the object now exists at the revised version. If you attempt
to revert to the original object version by refreshing the workarea, the object
disappears from the workarea completely rather than existing at its original
version.
Workaround:
None.
Problem:
It is possible to create multiple identical objects in the same container
without raising a uniqueness violation. An object can be created in a container
in the context of one workarea and an identical object (e.g. with the same
name in the same container) in the context of another workarea. If a workarea
is created (or recompiled) which includes both objects (for example by including
all objects within the container), the name uniqueness rules are violated
without an error being raised.
Workaround:
Manually perform name uniqueness check after workarea compilation.
When creating a folder mapping, extra files called .RVI files are created. The repository uses .RVI files to store information about which file and folder objects have been updated. Do not delete these .RVI files.
If a repository containing tables with LOB columns is backed up, the tables with LOB columns must be restored to a tablespace with the same name as the original, otherwise the restore fails with the message:
ORA-00959: tablespace 'tablespace_name' does not exist
If a repository is restored from a backup that contains tables with columns based on types (e.g. SDW_USERS and SDW_ACCESS_RIGHTS) and a type name with the same object identifier (OID) as one being imported already exists anywhere in the target database, neither the types nor the tables are restored. The following error messages are displayed:
IMP-00015: following statement failed because the object already exist: "CREATE TYPE ... " IMP-00061: Warning: Object type "..." already exists with a different identifier IMP-00063: Warning: Skipping table "..." because object type "..." cannot be created or has different identifier
However, if the same type name exists but with a different OID and the IGNORE parameter is set to Y, the types are imported followed by the tables.
When you initiate an action that is likely to take a while to complete, such as creating configurations, creating and refreshing workareas, or importing and exporting data, the relevant Wizard will display a dialog that shows the progress of the operation.
Note that the Cancel button on the progress dialog is not implemented; therefore you will not be able to cancel one of these operations while they are in progress. Also note that if you do choose the Cancel button on the progress dialog, a message will be displayed to indicate that the operation is being canceled. Ignore this message.
This unexpected behavior is not known to cause any problems.
Problem:
If the database that is hosting the new 6i instance is created with
a multi-byte character set and this is different to that of the database hosting
the existing 6.0 instance, it is possible that during migration errors will
occur because character data has become too big. For example, if the 6.0 repository
used a character set of WE8ISO8859P1 but the target 6i database uses
UTF8 then characters in the range 128-255 will go from requiring 1 byte to
2 bytes to hold them. This would include all the none ASCII characters. If
an object in the repository had a name that included such a character, and
the name was already the maximum length for the column definition in which
it was stored, the migrated data becomes too large and raises an error during
migration when it is attempted to be inserted into the new repository.
Workaround:
Follow Oracle's recommendations for changing the character set of the 6.0
repository database before attempting to migrate to 6i.
If checking in to a default checkin branch using user-defined labeling, the version label becomes user label.
For information about automatic version labeling, refer to the online documentation.
Oracle SCM can be run under SVGA (recommended) or VGA.
We recommend that you set the system font size to Small Fonts (Control Panel
> Display > Settings > Font Size).
|
![]() Copyright © 2002, Oracle Corporation. All Rights Reserved. |