Solution Guide for Migrating Oracle on UNIX to SQL Server - Willy .Net

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 26916Developing: Applications —<strong>Migrating</strong> <strong>Oracle</strong> Pro*CIntroduction and GoalsThir d generation languages (3GL) such as C and C++ do not have the capability tointerface with databases. Databases can only communicate using the SQL fourthgeneration language (4GL). Using embedded SQL allows a database to interface directlywith the 3GL languages. Pro*C is <strong>Oracle</strong>'s proprietary interface to the C language whichpermits the use of embedded SQL.As discussed in the "Define the <strong>Solution</strong> Concept" section of Chapter 2, "EnvisioningPhase," there are four different strategies available <strong>for</strong> transitioning applications in an<strong>Oracle</strong> to Microsoft® SQL Server migration project. The strategies are:● Interoperate the application with UNIX● Port or rewrite the application to the Microsoft .NET plat<strong>for</strong>m● Port or rewrite the application to the Microsoft Win32® plat<strong>for</strong>m● Quick port using the Microsoft Windows® Services <strong>for</strong> UNIX 3.5 plat<strong>for</strong>mBecause Pro*C is specific to <strong>Oracle</strong>, migration strategies are limited. Interoperation andporting cannot be utilized because no methods exist that allow Pro*C to communicatewith SQL Server. A complete rewrite is the only option.This chapter focuses on the preferred scenario that can be used in Pro*C applicationmigrations: Scenario 1: Rewriting the application to the .NET plat<strong>for</strong>m.Rewriting an application is a challenging endeavor because a one-to-one mapping fromthe source environment to the target environment is very difficult to achieve. When anapplication is rewritten, there is always a risk that some functionality from the originalapplication may be lost during the transition. Commonly, Pro*C programs are proceduraland do not have a graphical user interface. <strong>Migrating</strong> procedural code is easier thanmigrating GUI-based applications. Extensive testing needs to be per<strong>for</strong>med on therewritten application to ensure that all of the business logic and functionality hasaccurately been recreated.This chapter only discusses the trans<strong>for</strong>mation that needs to occur to the most commondatabase-related components when rewriting a Pro*C application <strong>for</strong> the .NETenvironment. A comprehensive study of the entire rewrite is beyond the scope of thisguidance.