SQL Tran Docs
  • Overview
    • About
    • Getting started
    • Object lifecycle
    • Why is there no AI inside?
    • Performance considerations
    • Security considerations
    • Assessment
    • Unlocking projects
    • Interface walk-through
    • Translation scenarios
    • Prerequisites for Azure Marketplace deployment
  • Emulation Scenarios
    • Emulation in SQL Tran
    • SQL Server to Fabric Warehouse
      • Data types
      • Case sensitivity
      • Cursors
        • Basic cursor loop
        • Cursor types
        • Fetch direction modes
        • Cursors in control flow
        • Nested cursors
        • Data modification cursors
        • Multiple cursors
        • Subqueries and filtering
      • Named procedure parameters
      • Result set limiting
      • MERGE statements
      • Computed columns
      • External tables
      • Materialized views
      • Identity columns
      • Unsupported system objects
    • Synapse Analytics to Fabric Warehouse
      • Emulations
      • Limitations
    • SQL Server to Synapse Analytics
    • Oracle to PostgreSQL
  • Project wizard
    • Source database
    • Target database
    • Wrapping up
  • Projects
    • Project list
    • Overview
    • Workspace
    • Reports
    • Tests
    • Scratch pad
    • Settings
      • Project name
      • Mapping
      • Database connections
    • Navigation
    • Object complexity
    • Static analysis
    • Translation errors
    • Exporting and importing projects
  • Workspace
    • Object tree
    • Data lineage
    • Code
    • Actions
      • Overriding source
      • Overriding target
      • Ignoring objects
  • Tests
    • Workflow
    • Configure SQL Tran
    • Connecting to databases
      • Fabric Warehouse
      • Synapse Dedicated SQL Pool
      • Azure SQL Database, Azure SQL Managed Instance, Microsoft SQL Server
    • Tables
    • Views
    • Procedures
    • Functions
    • Triggers
    • Performance tests
  • Scripter
    • About
    • Supported databases
    • SQL Server
    • Azure SQL
    • Synapse Dedicated Pool
    • Oracle
    • PostgreSQL
    • MySQL
Powered by GitBook
On this page
  1. Projects
  2. Settings

Mapping

PreviousProject nameNextDatabase connections

Last updated 5 months ago

Predefined mappings

  • Db as Schema prefix ‍This setting will prefix the schema names with the database name, helping to preserve the origin of the schema when the database name is crucial for identification.

  • Db as Schema, Schema as Table prefix ‍Here, the original database name becomes the schema name, and the original schema name is used as a prefix for table names, which is useful when merging multiple databases into a single schema.

  • Alias as Schema prefix ‍With this option, an alias defined within the migration tool is used as a prefix for the schema names, allowing for customization and easier identification in the target system.

  • Alias as Schema, Schema as Table prefix ‍This choice takes an alias for the database name and uses it as the schema name, while the original schema name is prefixed to the table names, maintaining a clear structure when the original database name should not or cannot be used directly.

Schema names

The Schema names section in database migration settings lets you define rules to translate schema names from the source to the target database using a "SOURCE=TARGET" format. The tool processes only the first rule that matches each schema and supports placeholders like {db} for the database name, {alias} for database alias, {schema} for the schema name, and {table} for the table name, which will be automatically replaced with the actual names during the migration.

Table names

Allows for the specification of renaming rules from source to target databases, using the "SOURCE=TARGET" syntax, with only the first applicable rule being executed per table. It supports placeholders such as {db} for the database name, {alias} for the database alias, {schema} for the schema name, and {table} for the table name, which are dynamically replaced with their corresponding values during the migration.

Column names

In the Column names configuration, you can establish renaming conventions for columns by creating "SOURCE=TARGET" rules. The system will apply only the first matching rule for each column, disregarding subsequent matches.

Datatype mapping

Omni Loader will always map data types in such a way that data is not lost and that the target type is as close to the source type as possible. You can opt to change the way we map the data types, by forcing the whole type to be changed or just a length of the type.