Migration Options
When migrating business objects, there are three options for its
files:
- By default, both file metadata and actual file contents are written
to the export file for business objects exported with their revision chain.
3DSpace
UUencodes the file and writes it to the export data file, along with business
object metadata. Pointers to the files are guaranteed because the file is
recreated during import. In this case, any file sharing is lost, (as when
revisions use the same file list—each revision in the chain gets its own copy
of the file).
- Add the
!file clause to not include any file metadata or
content.
- Use the
!captured clause to not include captured store file
content. This option writes only the fully qualified path of checked in files
in the data file, along with business object metadata.
When migrating databases, most often the
!captured option is recommended. This option
facilitates the process, in that the .mix files will not be as large, and
therefore will not require as much disk space or processing time to complete
the migration. After the import is complete, the objects will point to the
appropriate files in the same location.
The key to keeping the file pointers accurate is keeping the store
path definitions consistent. For example, let's say the database from which we
are exporting has a captured store named "Released Data Store." The path of
this store is defined as "/company/released." To maintain pointer consistency
when using
!captured, the new database must also have a defined
captured store "Released Data Store" with the same path definition.
If objects are to be deleted and then reimported, use the
!captured option, but be sure to tar off any captured
store directories before deleting any objects. Once the objects are deleted,
the directories restored, and the objects imported, the files will be
associated with the appropriate objects.
Migrating Revision Chains
Files may be shared among revisions of a business object. This "file
sharing" concept was introduced to minimize storage requirements and is
primarily used with captured stores. However, this does mean special attention
is required when exporting and importing. Consider the following:
If the entire revision chain is not going to be exported and/or
imported into a new database, then the use of
!captured may result in lost files. For example, if
the business object Assembly 123 0 has three files checked in, and is then
revised to Assembly 123 1, this new revision shares the three files with the
original. As long as both are exported and imported,
!captured can be used (in fact, should be used to
avoid file duplicating). However, if just Assembly 123 1 is imported into a new
database, then NO file is imported, because Assembly 123 1 inherits files from
the previous revision, which is not in the database yet. If you import Assembly
123 0 later, Assembly 123 1 shows files.
If you want to import business objects that have revisions and put
them into a different vault, you must use a map file. If you attempt to use the
from vault clause with the
to vault clause, errors will occur.