About Local Vaults

When adaplets are used without SQL Loader enabled, the vault for all adapted objects is the foreign vault that holds the mapping file. When you use the adaplet for a data load operation, you must decide into which local vault the objects will be loaded. You can create new vaults to hold the newly loaded objects, or add them to existing vaults.

When you execute the MQL command to create the load files, you include the name of the vault or vaults into which the objects should be loaded.

Once you have to have an adaplet configured from MQL you issue this command:

MQL> export vault ADAPLET_VAULT into LOCAL_VAULT_1 {, LOCAL_VAULT2,…};

The result of that will be data files in the appropriate load format, along with a command script, loader.bat, that is executed to run the appropriate database utility with proper options.

When the load files are created, a round-robin assignment of the specified vaults is used. You can override these assignments for certain objects or types by adding one of the following to the appropriate type descriptions in the mapping file:

  • vault TABLE(COLUMN)

    This clause in the mapping file’s type description indicates to load the objects into specific vaults on a per object basis, based on metadata (a column in a table) in the adapted data source. You might need to add the column to the table description in the mapping file before you can reference it in the type’s description.

    If loading data from a foreign vault that is mapped to create a type hierarchy, do not use vault table(COLUMN. Instead, use default vault VAULTNAME in the type definitions in the mapping file to load all objects of one type into the same vault.

  • default vault VAULT_NAME

    This clause in a mapping file’s type description indicates to load all objects of this type into a specific or default vault, identified as VAULT_NAME.

These clauses only make sense when using the adaplet to load objects into 3DSpace. When SQL Loader is not enabled, these statements are ignored.