When you import a table that references a type, but a type of that name already exists in the database, Import attempts to verify that the preexisting type is, in fact, the type used by the table (rather than a different type that just happens to have the same name).
To do this, Import compares the type's unique identifier (TOID) with the identifier stored in the export file. Import will not import the table rows if the TOIDs do not match.
In some situations, you may not want this validation to occur on specified types (for example, if the types were created by a cartridge installation). You can use the
TOID_NOVALIDATE parameter to specify types to exclude from TOID comparison.
The syntax is as follows:
TOID_NOVALIDATE=([schemaname.]typename [, ...])
imp scott TABLES=jobs TOID_NOVALIDATE=typ1 imp scott TABLES=salaries TOID_NOVALIDATE=(fred.typ0,sally.typ2,typ3)
If you do not specify a schema name for the type, then it defaults to the schema of the importing user. For example, in the first preceding example, the type
typ1 defaults to
scott.typ1 and in the second example, the type
typ3 defaults to
TOID_NOVALIDATE deals only with table column types. It has no effect on table types.
The output of a typical import with excluded types would contain entries similar to the following:
[...] . importing IMP3's objects into IMP3 . . skipping TOID validation on type IMP2.TOIDTYP0 . . importing table "TOIDTAB3" [...]
When you inhibit validation of the type identifier, it is your responsibility to ensure that the attribute list of the imported type matches the attribute list of the existing type. If these attribute lists do not match, then results are unpredictable.