Migrate-DB methodology

LF Surrogate Technique

The LF Surrogate technique allows to re-engineer the database from DDS to DDL without needing to recompile the applications.

For each Physical File that is re-engineered into an SQL table, a Logical File called an LF Surrogate is generated. Existing applications will now address the Surrogate LF that has replaced the Physical File and will continue to function as before, EXCEPT that they will write and read data in the new SQL table.

For this to happen, the LF Surrogate, Transformed LF and SQL Table must have the following characteristics

Characteristics of the Surrogate LF

  • Same Name as the Original PF
  • Same Columns as the Original PF
  • Same Keywords as the Original PFF
  • Same Access Path as the Original PF
  • Same FLI as the Original PF
  • Points to the New SQL Table

Characteristics of the Transformed LF

  • Same Name as the Original LF
  • Same Columns as the Original LF
  • Same (explicit) Keywords as the Original LF
  • Same Access Path as the Original LF
  • Same FLI as the Original LF
  • Points to the New SQL Table(s)

Characteristics of the SQL Table

  • New meaningful System and Long Table Names
  • Column System names are preserved
  • New meaningful Long Column Names
  • Existing columns of the Original PF preserved
  • New columns added (Identity, Auditing, True Dates, FK’s, custom)
  • Preserve, Owner, Grants, Compilation parameters, Triggers and Journaling
  • Create SQL Indexes (only when they share Access Path with the Originating Keyed LF)

Completeness of the process

  • It preserves record formats and applies correct permissions, triggers, constraints, object ownership and compilation options- in the SQL tables
  • It retrieves access paths, generates SQL Indexes, and transforms related Views and Materialized Query Tables
  • It preserves existing journaling scheme or, if preferred, applies automatic schema journaling
  • It ensures existing applications compatibility by building a “Surrogate” Logical File for each Physical File, and creating a transformed Logical File for each existing Logical File
  • It checks for invalid data stored in the PF’s
  • It employs parallel processing and other techniques to minimize the downtime when data is copied from the original PF’s into the new SQL tables

Adds an Identity Column and other Auto-Maintained Columns

As Xcase for i creates new SQL Tables, it will include the all-important Identity columns as well as your choice of other automatically-maintained columns (User and Time Stamps, other auditing columns, true dates, normalized FK’s based on identity parents, custom fields) – without impacting existing applications.