Skip to main content


developerWorks  >  Information Management  >

Porting to DB2 for Linux, UNIX, and Windows

Technical resources and roadmap

developerWorks
OverviewPorting stepsResources
 Step 1. Assessment
 Step 2. Planning the project
 Step 3. Education and training
 Step 4. Development environment
 Step 5. Users, groups, and permissions
 Step 6. Porting the database structure
 Step 7. Porting the database objects
 Step 8. Additional database components and products
 Step 9. Application modifications
 Step 10. Interface modifications
 Step 11. Data migration
 Step 12. Performance tuning
 Step 13. Maintenance strategy
 Step 14. Acceptance testing
 Step 15. Documentation
 Step 16. Packaging
 Step 17. Support
 

Step 7. Porting database application objects

Checklist for porting database application objects
  • Analyze stored procedure code
  • Analyze user-defined function code
  • Analyze trigger code
  • Convert the stored procedures
  • Convert the user-defined functionss
  • Convert the triggers
  • Develop any customized user-defined functions or stored procedures to replace proprietary functions
  • Document and implement any logic or functionality in the application code that couldn't be ported in a database application object

Database application objects (stored procedures, triggers, and user-defined functions) are essentially business logic contained within the database. Usually these objects are written in a native SQL procedural language or a higher-level language that must be compiled and associated/bound to the target database for use. Often, some portion of these objects will have to be rewritten or, in extreme cases, moved to the application code in order to preserve the functionality of the source system. As a result, this step is usually one of the most time consuming and expensive in the porting process.

Retrieving the database application object definitions can often occur at the same time that the database structure is captured if the objects are written in an SQL-like procedural language and stored within the database. For objects written in higher-level languages (Java, C, and so on), this involves copying the source files to the DB2 system, and finding a compatible compiler and binding mechanism. This is usually a manual process. If SQL statements are embedded in these objects, they can sometimes be extracted and run through a porting or migration tool that can convert the syntax so that it is compatible with DB2. After that, the converted statements can be put back in the original code, and then compiled with the supported compiling and binding mechanism.

After converting the database application objects, extensive testing should be performed on the converted objects. This means that test data is needed before testing can occur. This would require that you do at least some of the work in Step 11. Data migration before you complete this step.

After the conversion is completed, some adjustments or tweaks may still be required. For example, if the code was converted using a tool, small adjustments might be needed to improve performance.




Back to top


 logo

Document options

Document options requiring JavaScript are not displayed


More resources
Information for IBM customers
Information for IBM business partners
DB2 Migrate Now!
Software Migration Project Office
IBM Migration Toolkit
Porting to DB2 for i5/OS
IBM Information Management Community

Special offers
Optimize database apps and services with pureQuery
Webcast: IBM solidDB
Webcast: Replication and change data

More offers