FAQ
===

**Does Migration Toolkit support the migration of packages?**

Migration Toolkit supports the migration of packages from an Oracle
database into EDB Postgres Advanced Server. See :ref:`Functionality overview <Overview>`  for
information about the migration support offered by EDB Postgres Advanced
Server.

**Is there a way to transfer only the data from the source database?**

Yes. Data transfer is supported as part of an online or offline
migration.

**Does Migration Toolkit support migration of tables that contain data
of the CLOB data type?**

Migration Toolkit does support migration of tables containing data of
the CLOB type.

**Does EDB Postgres Advanced Server support the enum data type?**

EDB Postgres Advanced Server doesn’t currently support the enum data
type but will support it in future releases. Until then, you can use a
check constraint to restrict the data added to an EDB Postgres Advanced
Server database. A check constraint defines a list of valid values that
a column can take.

The following code sample includes a simple example of a check
constraint that restricts the value of a column to one of three dept
types; ``sales`` , ``admin`` or ``technical`` .

.. code:: sql

   CREATE TABLE emp (
     emp_id INT NOT NULL PRIMARY KEY,
     dept VARCHAR(255) NOT NULL,

     CHECK (dept IN (sales, admin, technical))
   );

If you test the check constraint by entering a valid dept type, the
INSERT statement works without error:

.. code:: sql

   test=# INSERT INTO emp VALUES (7324, sales);

   INSERT 0 1

If you try to insert a value not included in the constraint (``support``
), EDB Postgres Advanced Server returns an error:

.. code:: sql

   test=# INSERT INTO emp VALUES (7325, support);

   ERROR: new row for relation "emp" violates check constraint "emp_dept_check"

**Does EDB Postgres Advanced Server support materialized views?**

Postgres doesn’t support materialized views compatible with Oracle
databases. To set up a materialized view/summary table in Postgres you
must manually create the triggers that maintain the summary
table. Automatic query rewrite isn’t currently supported. You must make
the application aware of the summary table’s existence.

**When I try to migrate from a MySQL database that includes a TIME data
type, I get the following error: Error Loading Data into Table: Bad
format for Time. Does Postgres support MySQL \`\` TIME`\` data types?**

Postgres doesn’t have a problem storing ``TIME`` data types as long as
the value of the hour component isn’t greater than 24.

Unlike Postgres, the MySQL ``TIME`` data type allows you to store a
value that represents either a ``TIME`` or an ``INTERVAL`` value. A
value stored in a MySQL ``TIME`` column that represents an ``INTERVAL``
value can potentially be out of the accepted range of a valid Postgres
``TIMESTAMP`` value. If, during the migration process, Postgres
encounters a value stored in a ``TIME`` data column that it perceives as
out of range, it returns an error.

**What use cases does the connection retry capability support?**

Database scope: The connection retry capability allows Migration Toolkit
to reconnect to the target database. Retry attempts for issues with the
source database are currently not supported.

Migration scope: This capability allows Migration Toolkit to retry
migrating data. Retry attempts for issues with the schema migration are
currently not supported.

Modality scope: This reconnection capability is available with the data
migration mode (``-dataOnly`` ). It’s also available for the data
migration step when you run a migration without specifying either the
``-dataOnly`` and ``-schemaOnly`` options.

**What do I do if there’s an error during a data migration that results
in the data for one or more of my tables not being fully migrated?**

If Migration Toolkit can’t reconnect successfully and one or more of the
tables weren’t fully migrated, restart the entire data migration (with
the ``-dataOnly`` option) or configure Migration Toolkit to migrate only
the tables that weren’t fully migrated in the previous run. You can use
``connRetryCount`` , ``connRetryInterval`` , and ``abortConnOnFailure``
to alter the retry configuration options.

If the source database was accepting write transactions while the
previous Migration Toolkit data migration was in process, perform the
full (all tables) data migration again to ensure that data migrated to
the destination database is in a consistent state.

If you can confirm that no write transactions were performed on the
source database while the previous migration was being performed, then
it’s safe to migrate only those tables that weren’t fully migrated.

**What do I do if there’s an error during a schema migration that
results in not all of my schema objects being fully migrated?**

Unfortunately, reconnection for schema migration errors isn’t supported
at this time. If Migration Toolkit can’t migrate all schemas, restart
the entire schema migration again (with the ``-schemaOnly`` option), or
configure Migration Toolkit to migrate only the schemas that weren’t
fully migrated in the previous run.