About Importing

When migrating objects or entire databases, you must import them in the listed order.

  1. Import all administrative objects.
  2. Import all business objects.
  3. Import workspaces from the same exported ASCII data file as was used to import Persons. For more information, see Importing Workspaces.
  4. Import properties of the administrative objects that have them. The same file that was used to import the administrative objects should be used. For more information, see Importing Properties.

For more migration strategies, see Migrating Databases.

This page discusses:

Import Command

Use the Import command to import administrative objects from an export file to a database. The export file must be in Exchange Format or in an XML format that follows the Matrix.dtd specification. 

import [list] [property] ADMIN_TYPE TYPE_PATTERN [OPTION_ITEM [OPTION_ITEM] . . .] 
from file FILENAME [use [FILE_TYPE FILE [FILE_TYPE FILE] . . .];

For more information, see MQL Command Reference: import Command.

Importing Servers

If a server object is imported (via MQL or Oracle) into a different Oracle instance or user than it was exported from, the username and password settings of the server must be modified before distributed access is available. This is particularly important if an upgrade will follow the import, since all servers must be accessible to the machine doing the upgrade.

Importing Workspaces

Workspaces contain a user's queries, sets, and IconMail, as well as all Visuals. Workspaces are always exported with the person they are associated with. However, when Persons are imported, the workspace objects are not included. This is because they may rely on the existence of other objects, such as Types and business objects, which may not yet exist in the new database. Workspaces must be imported from the same .mix file that was used to import persons. For example: 

import workspace * from file admin.mix;

Or: 

import workspace julie from file person.mix;

Importing Properties

Properties are sometimes created to link administrative objects to one another. Like workspaces, properties are always exported with the administrative object they are on. Import is somewhat different; however, since a property may have a reference to another administrative object, and there is no way to ensure that the referenced object exists in the new database (administrative objects are sometimes exported and then imported in pieces). So a command to import administrative objects is issued, the specified objects are created first, and then the system attempts to import its properties. If the "continue" modifier is used, the system will get all the data it can, including system and user properties. But to ensure that all properties are imported, even when the administrative data may have been contained in several files, use the import property command.

For example, data can be exported from one database as follows: 

export attrib * into file attrib.exp; 
export program * into file program.exp; 
export type * into file type.exp; 
export person * into file person.exp;

Then the administrative objects are imported: 

import attrib * from file attrib.exp;
import program * from file program.exp;
import type * from file type.exp;
import person * from file person.exp;

Finally, workspaces and any "missed" properties are imported. Properties can exist on workspace objects, so it is best to import properties after workspaces: 

import workspace * from file person.exp;
import property attrib * from file attrib.exp;
import property program * from file program.exp;
import property type * from file type.exp;
import property person * from file person.exp;

Importing Index Objects

When importing an Index that includes attributes, these attributes must already exist in the new database, so you should import the attributes first. For example: 

import attribute A from file /temp/export.exp;
import attribute B from file /temp/export.exp;
import index * from file /temp/export.exp;

If the export file contains a lot of other admin data and you want to "import admin *", you can use import options to avoid errors when the attributes are processed. For example, if you know that you want the objects in the export file to supersede any objects of the same type/name in the database, use the following: 

import admin * overwrite from file /temp/export.exp;

If you want objects already in the database to remain unchanged, use: 

import admin * commit 1 continue from file /temp/export.exp;

Extracting from Export Files

Sometimes export files contain more information than you want imported. When this is the case, the extract command can be used to create a new file containing only the specified information of the original file. For more information, see MQL Command Reference: extract Command.