What does Full Convert migrate?

In short, Full Convert migrates tables, indexes, foreign keys and data.

Tables

All datatypes are mapped to the closest matching datatype in target database. You can override mapping per-table in Customize Table dialog, or globally in our options

Commonly used default values, like GETDATE(), are translated to equivalents in target database. Not all functions are translated.

If source database is relational, you can use native SQL expressions to transform data on the fly. An example would be0: trim(first_name + ' ' + last_name)

Indexes

We migrate primary keys, unique indexes, all standard indexes. Multi-column indexes are fully supported, as well as descending columns.

Exceptions

  • CSV: there are no indexes (inherent limitation of CSV, nothing to do with our software)
  • dBase/Visual FoxPro: expression index fields are skipped, as target databases usually have no equivalent functionality 
  • Excel: there are no indexes (inherent limitation of Excel, nothing to do with our software)
  • Paradox: only primary keys are converted
  • Sybase Advantage: expression index fields are skipped. We don't make distinction between primary/unique/standard ones (all are currently read as standard indexes).

Foreign keys

Relationships between tables (foreign keys) are fully supported.

If you start getting unexpected errors in foreign keys migration:

  • Check that your source data conforms to referential integrity rules
  • If source database is case-sensitive, you probably have target with case-insensitive collation. Fix that, then try the migration

Exceptions

  • CSV: there are no foreign keys (inherent limitation of CSV, nothing to do with our software)
  • dBase/Visual FoxPro: we don't read foreign keys
  • Excel: there are no foreign keys (inherent limitation of Excel, nothing to do with our software)
  • Paradox: we don't read foreign keys
  • Sybase Advantage: we don't read foreign keys

Data

We support tables of literally unlimited size. Hundreds of millions of records. Hundreds of gigabytes. Our customers proved that many times. For such huge tables we require that they have primary or unique key defined if source database is relational.

BLOB and memo fields are fully supported.

We take advantage of BULK inserts, LOAD, Oracle fast loader and all other available speedup methods to achieve as fast conversion as possible, with no risk of data corruption. We achieved data throughput of more than several hundred thousand records per second in internal testing. Of course, your mileage my vary and throughput you will see highly depends on type of databases used (especially target database), network throughput and performance of computers you use.

Still need help? Contact Us Contact Us