Identify SQL syntax differences between source database and DB2
Identify error handling differences between source database and DB2
Identify isolation level requirements of the application
Adjust SQL syntax to account for differences between source database and DB2
Implement any special error handling logic needed for DB2
Select the appropriate isolation level for transactions and SQL statements for DB2
While the porting of the database structure and objects can be automated to some extent using porting and migration tools, application code changes will mostly require manual effort. If all database interaction is restricted to a database access layer, then the scope and complexity of necessary changes is well defined and manageable. However, when database access is not isolated to a database access layer (that is, it is distributed throughout application code files, contained in stored procedures, triggers, or both, or used in batch programs that interact with the database), then the effort required to convert and test the application code depends on how distributed the database access is and on the number of statements in each application source file that requires conversion.
When porting an application, it is important to migrate the database structure (tables, views, indexes, and so on.) and database application objects (stored procedures, triggers, user-defined functions, and so on) first. It is then useful to populate the database with a set of test data so that the application code can be ported and tested incrementally.
Few tools are available to port actual application code since much of the work is dependent on vendor-specific issues. These issues include adjustments to logic to compensate for differing approaches for locking, transaction handling, SQL syntax, and use of special system tables. Manual effort is typically required to make and test these adjustments. Often, proprietary functions used in the source DBMS will need to be emulated in DB2, usually by creating a DB2 user-defined function, stored procedure, or both with the same name as the proprietary one being ported. This way, any SQL statements in the application code that call the proprietary function in question will not need to be altered. Migration tools such as the IBM Migration Toolkit are equipped with some of the most commonly used vendor-specific functions and will automatically deploy a DB2-equivalent function (or stored procedure) during the migration process.
The DB2 porting guides outline the necessary code changes that are needed for an application to work successfully with DB2. Applications written in a high-level language with embedded SQL can be converted automatically to some extent by extracting the SQL statements from the source, converting them with a porting or migration tool, and re-inserting them into the application code.
Keep in mind that when porting certain programming languages (C, C++, COBOL, and more), compiler differences sometimes arise. Modifications to the application code may be required if a different compiler, object library, or both are used in the DB2 environment (which may be caused by the selection of a different hardware or operating system platform). It is vital to fully debug and test such idiosyncrasies before moving a system into production.
For more information on various application development topics relating to DB2 (including code samples), visit the DB2 application development Web page.
