Overview

This article provides troubleshooting tips and instructions for common issues encountered when setting up and using G-Migration+. Troubleshooting topics may cover multiple types of databases. Please locate the problem and follow the recommended steps to resolve it. If this doesn't resolve the issue, please reach out to our support team at support@genrocket.com for additional help.

1. MSSQL Field Terminator Issue

2. PostgreSQL – Do Not Use Multi-Character Field Terminators

3. Oracle – Schema Name Should Be Treated as Database Name

4. MSSQL, PostgreSQL, or any other schema-based database – Schema Name Should Be Kept Empty for Cross-Schema Referential Integrity

5. Running Migration Only for Selected Tables (XTS File Configuration)

General Troubleshooting Tips


1. MSSQL Field Terminator Issue

Problem:
In G-Migration+, the default field terminator for MSSQL is set to a tab character. However, the standard or expected field terminator should be a tilde (~), which can cause issues during data extraction or migration.

Solution:
To correct the field terminator issue in MSSQL migration, follow these steps:

  • Step 1: Open each Domain’s receivers.
  • Step 2: Locate the Field Terminator setting under the MSSQLPartitionReceiver.
  • Step 3: Change the field terminator from the default tab (\t) to tilde (~).


Note: If your database contains special characters or uses a different field delimiter, please make sure the terminator is set correctly to prevent data misinterpretation.

 

2. PostgreSQL – Do Not Use Multi-Character Field Terminators

Problem:
PostgreSQL does not support multi-character field terminators (e.g., ~~ or ,,). This may cause issues when migrating the data using a multi-character terminator.


Solution:
When configuring the field terminator for PostgreSQL, ensure you are using only single characters as the field delimiter. For example: , (comma), ~ (tilde), or | (pipe) are acceptable options.


Note: Always validate the field terminator with your PostgreSQL database to avoid any character mismatch issues. If you are using a comma as a terminator and one of the column values also contains the comma, the migration will fail.

3. Oracle – Schema Name Should Be Treated as Database Name

Problem:
In Oracle migrations, the schema name is being treated incorrectly, which could lead to data mapping issues. The schema name in Oracle should be treated as a database name to ensure proper reference during migration.

Solution:
To fix the schema name handling issue in Oracle:

  • Step 1: Ensure that your Oracle source and destination databases are correctly identified in the migration configuration.
  • Step 2: Modify the configuration where the database or schema name is mapped. Make sure to treat the schema name as the database name and keep the schemaName field empty.


4. MSSQL, PostgreSQL, or any other schema-based database – Schema Name Should Be Kept Empty for Cross-Schema Referential Integrity

Problem:
During MSSQL, PostgreSQL, or any other schema-based database migrations, referential integrity may span across multiple schemas. When the schema name is explicitly provided in the migration configuration, the migration tool may only consider tables within that schema. This creates issues where parent or dependent tables from other schemas are not detected, resulting in foreign key violations, missing dependencies, or incomplete migrations.

Solution:
To fix this:

  • Step 1: Identify if your MSSQL, PostgreSQL, or any other schema-based database source contains foreign key references across multiple schemas (e.g., schemaA.table1 → schemaB.table2).

  • Step 2: Update the migration configuration by removing the schemaName value or setting it to empty. This allows the migration tool to automatically discover and include all related tables from every schema.

 

 

5. Running Migration Only for Selected Tables (XTS File Configuration)

Problem:
When running a migration for only a few tables, users often forget to configure the exclusion list correctly or fail to generate the necessary XTS (eXtended Table Selection) file for each table.

Solution:
To run the migration for specific tables only, follow these steps:

  • Step 1: Generate the XTS file by extracting all the tables
  • Step 2: Import the XTS file in the migration dashboard 
  • Step 3: For tables you do not want to migrate, add them to the Exclusion Tab in your migration configuration. 
    • Ensure that all unnecessary tables are correctly excluded from the migration process.
    • Double-check the XTS files and exclusion settings to avoid mistakenly including unwanted tables.
  • Step 4: Once the XTS files are correctly set up and the exclusion rules applied, execute the migration for only the selected tables.

 

General Troubleshooting Tips:

  • Check Field Terminators: Always ensure that you have specified the correct field terminator.
  • Database Mappings: Verify that all database and schema mappings are correctly configured to avoid any issues during the migration process..
  • XTS File Configuration: When running a partial migration, ensure the XTS file includes all tables, and use the Exclusion Tab to manage exclusions.