By Bill Ramos and Vishal Soni, Advaiya Inc.

This blog post covers the reasons why SQL Server Migration Assistant (SSMA) for Oracle does not support Collection or Records Type. A collection is an ordered group of elements, all of the same type. It is a general concept that encompasses lists, arrays, and other familiar data types. Each element has a unique subscript that determines its position in the collection.

Error O2SS0408 Collection or Record Type is not supported

Background

Whenever you make a reference of a user defined data type in collection query, SSMA is not able to resolve that data type. Hence, when you try to insert the values in table, SSMA generates an error. SSMA provides direct emulation of only the Integer and String data type and rest of the things are treated as Records.

Possible Remedies

Consider the below example:

When SSMA tries to convert the above code, it does not resolve the operations to be performed on the user defined datatype and hence generates “Error O2SS0408 Collection or Record Type is not supported”.

The solution of the above error is to rewrite the code in Oracle. Instead of creating a user defined data type separately, just declare a data type as a record of INTEGER data type and make its reference while assigning the values.

Corresponding SQL Server code generated by SSMA

Related Errors

There are several other errors related to “Collection and Records” that you may encounter. These include the following:

·         Emulating Records and Collections using CLR UDTs

·         Error O2SS0407 Unsupported collection key type

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Mayank Bhanawat, Advaiya Inc.

This blog post describes why SQL Server Migration Assistant (SSMA) for Oracle doesn’t convert the EXIT statement when an outer loop is exited from inside the scope of inner loop. The LOOP statement is used to define a loop with an indeterminate number of iterations. The EXIT statement exits a loop and transfers control immediately to the end of the loop.

Error O2SS0029 Cannot convert EXIT statement

Background

Whenever an outer loop is exited from inside the scope of inner loop, SSMA cannot always convert the exit statement and generates following error:‘Error O2SS0029 Cannot convert EXIT statement’

Possible Remedies

Consider the example below in which outer loop is exited from inside the scope of inner loop.

DECLARE

  s      PLS_INTEGER := 0;

  i      PLS_INTEGER := 0;

  j      PLS_INTEGER;

BEGIN

  <<outer_loop>>

  LOOP

    i := i + 1;

    j := 0;

    <<inner_loop>>

    LOOP

        j := j + 1;

        s := s + i * j; -- sum a bunch of products

        DBMS_OUTPUT.PUT_LINE('i: ' || TO_CHAR(i));

        DBMS_OUTPUT.PUT_LINE('j: ' || TO_CHAR(j));

        DBMS_OUTPUT.PUT_LINE('s: ' || TO_CHAR(s));

      EXIT inner_loop WHEN (j > 5);

      EXIT outer_loop WHEN ((i * j) > 15);

    ENDLOOP inner_loop;

  ENDLOOP outer_loop;

  DBMS_OUTPUT.PUT_LINE('The sum of products equals: ' || TO_CHAR(s));

END;

When SSMA tries to convert the above code, it generates following error:“Error O2SS0029 Cannot convert EXIT statement”.

The solution of the above problem is, first close the inner loop (ENDLOOP inner_loop;) and then EXIT the outer loop as shown below in the highlighted code:

DECLARE

  s      PLS_INTEGER := 0;

  i      PLS_INTEGER := 0;

j      PLS_INTEGER;

BEGIN

  <<outer_loop>>

  LOOP

    i := i + 1;

    j := 0;

    <<inner_loop>>

    LOOP

        j := j + 1;

        s := s + i * j; -- sum a bunch of products

        DBMS_OUTPUT.PUT_LINE('i: ' || TO_CHAR(i));

        DBMS_OUTPUT.PUT_LINE('j: ' || TO_CHAR(j));

        DBMS_OUTPUT.PUT_LINE('s: ' || TO_CHAR(s));

      EXIT inner_loop WHEN (j > 5);

  ENDLOOP inner_loop;

EXIT outer_loop WHEN ((i * j) > 15);

  ENDLOOP outer_loop;

  DBMS_OUTPUT.PUT_LINE('The sum of products equals: ' || TO_CHAR(s));

END;

When you execute the above code in SSMA, it executed successfully. But in this query, the loop iterates one time less than source example because in the resolution we have first closed the inner loop and then EXIT the outer loop.

The resolution of this problem is to use the GOTO approach in SQL Server. The GOTO statement is used to transfer control of program execution to the statement that has a specified statement label. For this, we need to update the SQL Server code as follows:

BEGIN

   DECLARE

      @s int = 0,

      @i int = 0,

      @j int

   condition1:

   WHILE (@i * @j) > 15 break

       BEGIN

         SET @i = @i + 1

         SET @j = 0

      condition2:

         WHILE1 = 1

            BEGIN

               PRINT 's: ' + ISNULL(CAST(@s ASvarchar(max)), '')                       

               IF ((@i * @j) > 15)   BREAK

                 SET @j = @j + 1

                 SET @s = @s + @i * @j                    

               IF (@j > 5) goto condition1

                 PRINT 'i: ' + ISNULL(CAST(@i ASvarchar(max)), '')

                 PRINT 'j: ' + ISNULL(CAST(@j ASvarchar(max)), '')

               IF ((@i * @j) > 15) goto condition2  

            END      

                     PRINT 'The sum of products equals: ' + ISNULL(CAST(@s ASvarchar(max)), '')    

       END

END

GO

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Mayank Bhanawat, Advaiya Inc.

This blog post describes why SQL Server Migration Assistant (SSMA) for Oracle doesn’t support the SAVE EXCEPTION clause in the FORALL statement. Exception handling is a programming language construct or mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution.  In Oracle, FORALL statement lets you run multiple DML statements very efficiently and can only repeat a single DML statement, unlike a general-purpose FOR loop. SAVE Exception statement is an optional keywords that cause the FORALL loop to continue even if some DML operations fail.

Error O2SS0343 FORALL statement with SAVE EXCEPTION clause is not supported

Background

The Oracle exception model differs from Microsoft SQL Server 2008 both in exception raising and exception handling. It is preferable to use the SQL Server exceptions model as part of the Oracle PL/SQL code migration.

Whenever FORALL statement used with SAVE exception clause, SSMA doesn’t support it and generate following error message:Error O2SS0343 FORALL statement with SAVE EXCEPTION clause is not supported.

Possible Remedies

Consider the example below which uses a FORALL statement with SAVE EXCEPTION clause.

CREATETABLE DIVISION_RESULT_Exception (RESULTNUMBER);

/

DECLARE

  TYPE NUMLIST ISTABLEOFNUMBER;

  NUM_TAB NUMLIST := NUMLIST(1000,0,100,0,10);

  ERRORSNUMBER;

  DML_ERRORS EXCEPTION;

  PRAGMA EXCEPTION_INIT(DML_ERRORS, -24381);

BEGIN

  FORALL i IN NUM_TAB.FIRST..NUM_TAB.LASTSAVEEXCEPTIONS

     INSERTINTO DIVISION_RESULT_Exception VALUES(1000/NUM_TAB(i));

EXCEPTION

WHEN DML_ERRORS THEN

  ERRORS := SQL%BULK_EXCEPTIONS.COUNT;

  DBMS_OUTPUT.PUT_LINE('Number of errors is ' || ERRORS);

  FOR i IN1..ERRORSLOOP

     DBMS_OUTPUT.PUT_LINE('SQLCODE: ' || SQL%BULK_EXCEPTIONS(i).ERROR_INDEX);

     DBMS_OUTPUT.PUT_LINE('SQLERRM: ' ||SQLERRM(-SQL%BULK_EXCEPTIONS(i).ERROR_CODE));

  ENDLOOP;

END;

When SSMA tries to convert the above code, it generates following error: “Error O2SS0343 FORALL statement with SAVE EXCEPTION clause is not supported”.

One possible remediation is to use the try and catch block to handle the exceptions in T-SQL using ERROR_NUMBER and ERROR_MESSAGE functions instead of the SQLCODE and SQLERRM Oracle functions. For this, we need to update the SQL Server code as follows:

BEGIN

/*Declaration and initialization of table of input values*/

   DECLARE

      @CollectionIndexInt$TYPE varchar(max)=' TABLE OF DOUBLE'

   DECLARE

      @NUM_TAB dbo.CollectionIndexInt = dbo.CollectionIndexInt ::[Null].SetType(@CollectionIndexInt$TYPE).AddDouble(1000).AddDouble(0).AddDouble(100).AddDouble(0).AddDouble(10),

/* Declaration and initialization of other variables*/

      @ERRORS int,

      @DML_ERRORS$exception nvarchar(1000)

        SET @DML_ERRORS$exception =N'ORA-24381%'

   DECLARE

/* Declaration and initialization of temporary variables */

      @i int

      SET @i = 1

/* Running the loop for all the input values*/

      WHILE @i <= @NUM_TAB.Count

      BEGIN

/* Performing the required operation in Try block */

        BEGINTRY

            INSERT dbo.DIVISION_RESULT_EXCEPTION(RESULT)

            VALUES (1000 / @NUM_TAB.GetDouble(@i))

        ENDTRY

/* Catch block to handle exception generated in Try block */

        BEGINCATCH

           set  @Errors = @Errors + 1;

          Print ('SQL error is '+convert(varchar(20),Error_Number())+':'+convert(varchar(100),ERROR_MESSAGE()))

           Print(Convert(Varchar(30),(Error_Number())))

        ENDCATCH;

/*Incrementing the loop variable*/          

  SET @i = @i + 1

      END

END

GO

Related Errors

There are several other errors related to “Exception Handling” that you may encounter. These include the following:

·         Error O2SS0282: RAISE without exception specified can be placed only in exception handler

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Badal Bordia, Advaiya Inc.

This blog post covers the reasons why SQL Server Migration Assistant (SSMA) for Oracle cannot get description for packaged function or a packaged procedure call when a parameter has been omitted.

A package is an encapsulated collection of related program objects (for example, procedures, functions, variables, constants, cursors, and exceptions) stored together in the database. To execute a function or procedure that is defined in a package, you'll have to prefix the function name (through required parameters) along with the package name

Error O2SS0101 A parameter has been omitted, so there is no default value 

Background

Whenever you invoke a function or procedure that is defined in a package with omitting invalid parameter, SSMA generated an error. When no values are passed to a packaged function or a packaged procedure call, the omitted parameters holding no default values causes this error.

Possible Remedies

Consider the below example of Oracle. In this example we have created a package (math_pkg) that contains a function (get_sum)

Package Specification and Package Body

CREATEORREPLACEPACKAGE math_pkg AS

   FUNCTION get_sum (n1 INT, n2 INTDEFAULT0, n3 INTDEFAULT0) RETURNINT;

END math_pkg;

CREATEORREPLACEPACKAGEBODY math_pkg AS

   FUNCTION get_sum (n1 INT, n2 INTDEFAULT0, n3 INTDEFAULT0) RETURNINTIS

   BEGIN

       RETURN n1 + n2 + n3;

   END;

END math_pkg;

Statement

DECLARE

addition INT;

BEGIN     

addition := math_pkg.get_sum();

END;

When SSMA tries to convert the above statement, it does not resolve the operations of called function (get_sum)that is invoked without required parameter passing or wrong number of arguments. Hence generates error “O2SS0101: A parameter has been omitted, so there is no default value: n1”.

The solution of the above error is to rewrite the code in Oracle. Actually in Oracle when you call the above package in the statement, it also raises the PL/SQL error of wrong number or types of arguments in call to 'GET_SUM'.

So you have to rectify the problem in Oracle itself by assigning optional value to parameter within a function. By doing this we are matching the number and types of argument required to invoke the function. To make a parameter optional you can set a default value in the case if the value is not passed, the default value will be taken. In Oracle the first two parameters are mandatory and only the last parameter is optional.

Below is the rewrite code of an above Oracle example- In below function defined in a package  we are assigning default value (n1 INT DEFAULT 0) to the first parameter of get_sum() function.

CREATEORREPLACEPACKAGE math_pkg AS

   FUNCTION get_sum (n1 INTDEFAULT0, n2 INTDEFAULT0, n3 INTDEFAULT0) RETURNINT;

END math_pkg;

CREATEORREPLACEPACKAGEBODY math_pkg AS

   FUNCTION get_sum (n1 INTDEFAULT0, n2 INTDEFAULT0, n3 INTDEFAULT0) RETURNINTIS

   BEGIN

       RETURN n1 + n2 + n3;

   END;

END math_pkg;

SSMA will now properly convert the code.

Related Errors

There are several other errors related to “Invalid parameter” that you may encounter. These include the following:

·         Error O2SS0102 Procedure (function) call is missing a parameter

·         Error O2SS0104 Unpackaged function call is missing a parameter

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Mayank Bhanawat, Advaiya Inc.

This blog post describes why SQL Server Migration Assistant (SSMA) for Oracle doesn’t convert the SELECT statement in two scenarios that have ill formed ORDER BY clauses.

Error O2SS0160 SELECT statement not converted

Background

There are two scenarios, in which SSMA doesn’t convert the select statement and generate the same ‘Error O2SS0160 SELECT statement not converted’ due to following reason:

·         When SELECT DISTINCT statement is used with CONNECT BY PRIOR statement in the hierarchical query, SSMA cannot convert the select statement.

·         When ORDER BY clause sorts the result set based on the two columns/fields but you have specify only one column/field in SELECT statement, SSMA cannot convert the select statement

Possible Remedies

Scenario 1:

Consider the example below in which SELECT DISTINCT statement is used with CONNECT BY PRIOR statement in the hierarchical query.

SELECTdistinct empno, MGR, ename

    FROM emp

STARTWITH MGR = 7902

CONNECTBYPRIOR MGR = empno;

When SSMA tries to convert the above code, it generates following error:“Error O2SS0160 SELECT statement not converted”.

To resolve the above issue, you can use the ORDER BY statement in the source code of Oracle, as shown below: 

SELECTdistinct empno, MGR, ename

    FROM emp

STARTWITH MGR = 7902

CONNECTBYPRIOR MGR = empno

Orderby empno;

When you execute the above query in SSMA, it converts successfully.

Scenario2: Consider the other example in which ORDER BY clause sorts the result set based on the two columns/fields but SELECT statement only have one columns/field.

Select Empno from emp ORDERBY1, 2;

When SSMA tries to convert the above statement, it generates following “Error O2SS0160 SELECT statement not converted”.

If the number of fields/columns used with ORDER BY clause is greater than number of field/column in the SELECT statement than SSMA generate the error. To solve this error either reduce the number of field/column in ORDER BY statement or equalize number of field/column in both SELECT statement and ORDER BY statement.

To solve this issue in our example, we equalize the field/column of SELECT statement with ORDER BY statement by removing the second column reference from the ORDER BY clause as shown below:

Select Deptno from emp ORDERBY1;

When you execute the above code in SSMA, it converts successfully.

Related Errors

There are several other errors related to “Hierarchical query” that you may encounter. These include the following:

·         Error O2SS0268: Hierarchical query with outer join cannot be converted

·         Error O2SS0285: Hierarchical query was not converted

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Vishal Soni, Advaiya Inc.

This blog post describes why SQL Server Migration Assistant (SSMA) for Oracle doesn’t convert the PL/SQL block when using invalid syntax while creating a package in Oracle code.

Error O2SS0418 Failed to parse statement batch with package definition

Background

Whenever we used the invalid syntax while creating a package in Oracle code, SSMA generates following error: “Error O2SS0418 Failed to parse statement batch with package definition”

Possible Remedies

Consider the example below, in which we have created a package Empty_Pkg4 with invalid syntax:

CREATEORREPLACEpackage Empty_Pkg4

IS

Begin

PVT INT := 10;

END;

When SSMA tries to convert the above statement, it generates following error: “Error O2SS0418 Failed to parse statement batch with package definition”.

To resolve this error, you can correct the source code and delete the invalid syntax in Oracle. In our example we have to delete the Begin statement from the Oracle source code as shown below:

CREATEORREPLACEpackage Empty_Pkg4

IS

PVT INT := 10;

END;

When you convert the above code in SSMA, it converted successfully.

Another remedy to consider is verifying if any application code calls the package containing the invalid syntax. If not, consider removing the package from your migration project.

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Vishal Soni, Advaiya Inc.

This blog post covers the reason why SQL Server Migration Assistant (SSMA) for Oracle cannot convert some of the statements that have cursor as a return type in any function.

A cursor is a mechanism by which you can assign a name to a "SELECT statement" and manipulate the information within that SQL statement. Cursors are used by database programmers to process individual rows returned by database system queries.

Error O2SS0274 Call to function with cursor return value cannot be converted in current context

Background

In SSMA, the conversion of cursors in return statements is not supported. So if a function is defined with a cursor as return type, then SSMA generates Error O2SS0274.

Possible Remedies

Consider the following example:

CREATEORREPLACEFUNCTION F_RETURN_CUR

   RETURN SYS_REFCURSOR

IS

   refCursorValue SYS_REFCURSOR;

BEGIN

   OPEN refCursorValue

   FORSELECT*FROM dept;

   RETURN (refCursorValue);

END;

DECLARE

   refCursorValue SYS_REFCURSOR;

   myRecord dept%ROWTYPE;

BEGIN

   refCursorValue := F_RETURN_CUR;

   LOOP

      FETCH refCursorValue

         INTO myRecord;

      EXITWHEN refCursorValue%NOTFOUND;

      dbms_output.put_line(refCursorValue%ROWCOUNT);

   ENDLOOP;

END;

When you execute the above code in Oracle, a function with name “F_RETURN_CUR” is created. This function returns the cursor refCursorValue. While migrating this function, SSMA generates the error “Error O2SS0274 Call to function with cursor return value cannot be converted in current context”.

One possible remediation is to create and use temporary table inside the function in SQL Server instead of using cursor. And then the reference of this temporary table is returned by the function. For this, we need to update the SQL Server code as follows:

CREATEFUNCTION dbo.F_RETURN_CUR(@Choice int)

RETURNS @TempEmp TABLE

(

   [DEPTNO] [numeric](4, 0)NOTNULL,

   [DNAME] [varchar](10)NOTNULL

)

AS

BEGIN 

   INSERTINTO @TempEmp

   SELECT*FROM dept;                

RETURN;

END

BEGIN

   DECLARE

      @v_refCursorValue_rowcount int,

      @refCursorValue CURSOR

   DECLARE

      @myRecord$DEPTNO float(53),

      @myRecord$DNAME varchar(20)

   DECLARE

    @TableVariable TABLE (DEPTNO INT, DNAME NVARCHAR)

    SET @refCursorValue =CURSORFORSELECT*FROM F_RETURN_CUR(1)

    OPEN @refCursorValue

SET @v_refCursorValue_rowcount = 0

   WHILE 1 = 1

     BEGIN

        FETCH @refCursorValue

          INTO @myRecord$DEPTNO, @myRecord$DNAME

            IF@@FETCH_STATUS= 0

              SET @v_refCursorValue_rowcount = @v_refCursorValue_rowcount + 1

            IF@@FETCH_STATUS<> 0

              BREAK

            PRINT @v_refCursorValue_rowcount

      END

END

GO

Related Errors

There are several other errors related to returning a CURSOR that you may encounter. These include the following:

·         Error O2SS0245 - Cursor conversion in return statements not supported

·         Error O2SS0094 Unable to convert CURSOR as parameter.

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Ankit Matta, Advaiya Inc.

This blog post covers the reason why SQL Server Migration Assistant (SSMA) for Oracle is not able to convert a BINARY_FLOAT column with a constraint for checking a NAN (Not a Number) condition. In Oracle, the BINARY_FLOAT data type allows an application to store number underflow or overflow values. SQL Server generates an error as soon as a number overflow or underflow is computed and thus can’t store the value in a FLOAT data type.

Error O2SS0007 Check constraint condition not parsed

Background

When you try to convert the schema of a table having a constraint condition which is checking for NAN values, SSMA generates an error “Error O2SS0007 Check constraint condition not parsed” becauseSQL Server doesn’t support floating point conditions like NAN.

Possible Remedies

Consider the below example where we have created a table and altered it by adding a constraint of NAN type:

CREATETABLE NANTEST

(

      COL1 BINARY_FLOAT

);

/

ALTERTABLE NANTEST ADDCONSTRAINT NANCHECK1 CHECK (COL1 ISNOT NAN);

When you try to convert the schema of the above table in SSMA, it generates the below error message:

The solution of the above error can be, divided into 2 steps

Step 1: Create a new table in SQL Server [The equivalent of BINARY_FLOAT in SQL Server is FLOAT(53)] without including the check constraint.

CREATETABLE NANTEST

(

      COL1 FLOAT(53)

)

Step 2: Modify the application code for inserting the values in this table. Create a TRY… CATCH block which would be restricting the users to insert an unsupported value and generate an error message similar to an error generated from a check constraint.

DECLARE

      @VAL FLOAT(53)

BEGIN TRY

      SET @VAL = 1/0

      INSERTINTO NANTEST VALUES (@VAL)

END TRY

BEGIN CATCH

      Print ('SQL error is ' + convert(varchar(20),Error_Number()) + ' : ' + convert(varchar(100),ERROR_MESSAGE()))

END CATCH;

Trying to use the Transact-SQL ISNUMERIC() function in a check constraint for this scenario is not a viable solution in the check constraint because ISNUMERIC() is designed to check for strings that might represent numeric values and not numeric underflow and overflow conditions.

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Ankit Matta, Advaiya Inc.

This blog post covers one of the reasons why SQL Server Migration Assistant (SSMA) for Oracle cannot convert a hierarchical query containing complex functions in any sub query. A hierarchical query is a type of SQL query that handles hierarchical model data. For each hierarchical query one has to specify a starting condition with the START WITH clause, which will trickle down to all dependent rows using one or more conditions specified by the CONNECT BY clause.

Error O2SS0038 Hierarchical query not converted

Background

When converting the hierarchical query, SSMA provides emulation. SSMA emulates it to a corresponding solution as a recursive query. Note: A recursive CTE can greatly simplify the code required to run a recursive query within a statement. Oracle's START WITH clause becomes the first nested SELECT, the base case of the recursion, to be UNIONed with the recursive part which is just another SELECT.

Whenaggregatefunction (i.e. MAX, MIN, etc.) is used as a part of sub query in a hierarchical query, SSMA cannot convert the hierarchical query to corresponding SQL Server query and generates the O2SS0038 error message.

Possible Remedies

Consider the following example that has an aggregate function (i.e. MAX, MIN, etc.) used as a part of sub query in a hierarchical query:

CREATEORREPLACEPROCEDURE  Hierarchy_Test AS

BEGIN

  FOR c IN (

SELECT p.id, p.NAME, p.parent_id, pp.podr_cod, pp.count_chel, pp.date_start, pp.date_finish, pp.parent_podr_id

                  FROM podr p,

                  (SELECT *

                   FROM podr_param pp

                   WHERE pp.ROWID = (SELECTSUBSTR(MAX(TO_CHAR(date_start,'YYYYMMDD')||rowid),9)

                                     FROM podr_param

                                     WHERE podr_id=pp.podr_id)) pp

                   WHERE p.id = pp.podr_id

                   STARTWITH p.id = 123

                   CONNECTBYPRIOR p.id = pp.parent_podr_id)

LOOP

dbms_output.put_line(RPAD(c.id||'  ',15) || RPAD(c.podr_cod||'  ',15) || RPAD(c.NAME||'  ',15) || RPAD(TO_CHAR(c.date_start,'DD.MM.YYYY')||'  ',15) || RPAD(TO_CHAR(c.date_finish,'DD.MM.YYYY'),15));

ENDLOOP;

END;

The solution is to simplify the nested sub query containing any aggregate Function. In our example, the hierarchical query containing aggregate function (MAX) in a sub query is not converted into the equivalent SQL query.

To resolve this error, we’ll create a new function in Oracle and call that function in the nested query. The function will calculate the desired value and pass it into the nested query. Below is the sample Function, for the above query:

CREATEORREPLACEfunction max_val(date_start DATE)

RETURNVARCHAR

IS val VARCHAR(20);

BEGIN

SELECTROWIDfrom podr_param WHERE date_start=(SELECTMAX(date_start)

INTO val

FROM podr_param);

RETURN (val);

END;

You can then call this function in within the modified procedure in the nested query and the error will be resolved. The end result would translate the Oracle's START WITH clause into the first nested SELECT, and UNION it with the recursive part which is just another SELECT.

Below is the example of the simplified procedure along with the screenshot of the converted query:

CREATEORREPLACEPROCEDURE Hierarchy_Test AS

BEGIN

FOR c IN (

SELECT p.id, p.NAME, p.parent_id, pp.podr_cod, pp.count_chel,   pp.date_start, pp.date_finish, pp.parent_podr_id

              FROM podr p,

              (SELECT *

               FROM podr_param pp

               WHERE pp.ROWID = max_val(date_start)) pp

           WHERE p.id = pp.podr_id

           STARTWITH p.id = 123

           CONNECTBYPRIOR p.id = pp.parent_podr_id) LOOP

dbms_output.put_line(RPAD(c.id||'  ',15) || RPAD(c.podr_cod||'  ',15) || RPAD(c.NAME||'  ',15) || RPAD(TO_CHAR(c.date_start,'DD.MM.YYYY')||'  ',15) || RPAD(TO_CHAR(c.date_finish,'DD.MM.YYYY'),15));

ENDLOOP;

END;

You can now use SSMA to convert the result to SQL Server without errors as shown below.

Related Errors

There are several other errors related to Hierarchical queries that you may encounter. These include the following:

• O2SS0047 Hierarchical queries with asterisk not supported
• O2SS0119 Hierarchical queries in sub query factoring clauses are not supported
• O2SS0268 Hierarchical query with outer join cannot be converted
• O2SS0285 Hierarchical query was not converted

In most of these situations, consider what the query is trying to accomplish and rewrite it to use the emulation.

References

For more information, check out the following references.

Migrating Oracle to SQL Server 2008 White Paper

Recursive Queries Using Common Table Expressions

By Bill Ramos and Ankit Matta, Advaiya Inc.

This blog post covers the reason why SQL Server Migration Assistant (SSMA) for Oracle does not convert the wrapped code. Wrapping (encrypting) is a process of hiding the source code. Wrapping helps to protect the source code from the competitors and others who might misuse it. In Oracle, one can wrap the source code using DBMS_DDL subprograms.

Error O2SS0260 Wrapped package cannot be converted

Background

Whenever you try to convert the WRAPed (encrypted) PL/SQL code, SSMA gives a warning message saying that the “Required code is wrapped”.  When you skip this warning by clicking Continue button, SSMA generates an error message, “Error O2SS0260 Wrapped package cannot be converted”. Also, you will be able to view only the Conversion statistics and not the code in the Assessment Report window, as the code is wrapped.

Possible Remedies

Consider the below example, where we have declared two variables, one to store the Package specification and another to store Package body as strings. These variables are then passed to a predefined stored procedure “DBMS_DDL.CREATE_WRAPPED”, which will create a wrapped package.

DECLARE

  src_pkg_header       VARCHAR2(32767);

  src_pkg_body         VARCHAR2(32767);

BEGIN

  src_pkg_header

      := 'CREATE OR REPLACE PACKAGE Wrapped_PKG IS '

      || 'x pls_integer; '

      || 'END Wrapped_PKG; ';

  src_pkg_body

      := 'CREATE OR REPLACE PACKAGE BODY Wrapped_PKG IS '

      || 'BEGIN '

      || 'x := 10; '

      || 'END Wrapped_PKG;';

  SYS.DBMS_DDL.CREATE_WRAPPED(ddl => src_pkg_header);

  SYS.DBMS_DDL.CREATE_WRAPPED(ddl => src_pkg_body);

END;

When you execute the above code in Oracle, a package with name “Wrapped_PKG” is created. This package is created in encrypted format, so you cannot view the text/code inside this package.

When you try to convert the package “Wrapped_PKG” code using SSMA, you will get Error O2SS0260.

The solution of the above error can be divided into steps, mentioned below:

Step 1– Create and execute only the package code in Oracle. Then convert this code into corresponding SQL Server code using SSMA.

CREATEORREPLACEPACKAGE Wrapped_PKG IS

x pls_integer;

END Wrapped_PKG;

CREATEORREPLACEPACKAGEBODY Wrapped_PKG IS

BEGIN

x := 10;

END Wrapped_PKG;

Below is the corresponding SQL Server code for the above Package.

CREATEPROCEDURE dbo.WRAPPED_PKG$SSMA_Initialize_Package

AS

   EXECUTE sysdb.ssma_oracle.db_clean_storage

   EXECUTE sysdb.ssma_oracle.set_pv_int

      'PROSEWARE',

      'DBO',

      'WRAPPED_PKG',

      'X',

      10

GO   

Step 2 – Copy this codeand Just add “WITH ENCRYPTION” keyword as highlighted in the code below. This will encrypt your code in SQL Server.

CREATEPROCEDURE dbo.WRAPPED_PKG$SSMA_Initialize_Package

WITH ENCRYPTION

AS

   EXECUTE sysdb.ssma_oracle.db_clean_storage

   EXECUTE sysdb.ssma_oracle.set_pv_int

      'PROSEWARE',

      'DBO',

      'WRAPPED_PKG',

      'X',

      10

GO

For more information regarding the ENCRYPTION clause, please refer to the MSDN help topic – CREATE PROCEDURE (Transact-SQL).  In SSMA, when you try to MODIFY the procedure by right clicking the procedure name, the MODIFY option is disabled automatically.

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Mayank Bhanawat, Advaiya Inc.

This blog post describes why SQL Server Migration Assistant (SSMA) for Oracle doesn’t convert the PL/SQL block when outer joins are used in hierarchical queries.

In Oracle, CONNECT BY PRIOR is a condition that identifies the relationship between parent rows and child rows of the hierarchy. Outer Join includes data rows in the result set that do not have a match in the joined table and returns these missing columns as NULL values.

Error O2SS0268: Hierarchical query with outer join cannot be converted

Background

When an Outer Join statement is used with CONNECT BY PRIOR in hierarchical queries, SSMA doesn’t convert the statement and generate the following error ‘Error O2SS0268: Hierarchical query with outer join cannot be converted’

Possible Remedies

Consider the example below in which LEFT OUTER JOIN statement is used with CONNECT BY PRIOR statement in the hierarchical query.

Select e.empno, e1.empno, e1.mgr

From emp e LEFTOUTERJOIN emp1 e1

ON e.empno = e1.empno

Connectbyprior e1.mgr = e.deptno;

When SSMA tries to convert the above code, it generates following error:“Error O2SS0268”

To resolve the above issue, rewrite the SQL code by using recursive CTE method as shown below: 

With EMPTEMP (empno, ename, mgr) as

(

select empno, ename, MGR

  from   emp

  unionall

  select e.empno, e.ename, e.MGR

  from   emp e

         join    

         emp1 e1

         on (e1.mgr = e.deptno)

)

SELECT e2.EMPNO, e1.EMPNO AS empno$2, e1.mgr

FROM

   EMPTEMP AS e2

      LEFTOUTERJOIN EMP1 AS e1

      ON e2.EMPNO = e1.EMPNO

GO

Related Errors

There are several other errors related to “Hierarchical query” that you may encounter. These include the following:

·         Error O2SS0160: SELECT statement not converted

·         Error O2SS0285: Hierarchical query was not converted

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Vishal Soni, Advaiya Inc.

This blog post covers the reason why SQL Server Migration Assistant (SSMA) for Oracle cannot convert EXCEPTION_INIT.

Exception handling is a programming language construct or mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution. One can use the pragma EXCEPTION_INIT to associate exception names with other Oracle error codes that one can anticipate.

Error O2SS0054 Unable to convert EXCEPTION_INIT

Background

Whenever you try to convert PL/SQL code having an “EXCEPTION_INIT” exception with a user defined exception name in it, SSMA is unable to convert EXCEPTION_INIT because it doesn’t find an exception with the same name in the parameter section. Hence SSMA generates “Error O2SS0054 Unable to convert EXCEPTION_INIT”.

Possible Remedies

Consider the following example:

DECLARE

MYEXCEPTION EXCEPTION;

PRAGMA EXCEPTION_INIT(MYEXCEPTION_1, -20000);

BEGIN

NULL;

END;

When you execute this code in SSMA, it does not identify the user defined exception “MYEXCEPTION_1” and hence generates the error “Error O2SS0054 Unable to convert EXCEPTION_INIT”.

Note: - This is a bad code example of Oracle, as Oracle also generates an error message when you try to execute this code.

Remediation of this error is to use the same name while declaring and defining an exception. For this, update the code as follows:

DECLARE

MYEXCEPTION EXCEPTION;

PRAGMA EXCEPTION_INIT(MYEXCEPTION, -20000);

BEGIN

NULL;

END;

SSMA will convert the updated code with no errors.

Related Errors

There are several other errors related to Exceptions that you may encounter. These include the following:

·         Error O2SS0343 FORALL statement with SAVE EXCEPTION clause is not supported

·         O2SS0055 Incorrect EXCEPTION_INIT PRAGMA parameter

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper

By Bill Ramos and Ankit Matta, Advaiya Inc.

This blog post covers the reason why SQL Server Migration Assistant (SSMA) for Oracle cannot convert EXCEPTION_INIT.

Exception handling is a programming language construct or mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution. One can use the pragma EXCEPTION_INIT to associate exception names with other Oracle error codes that one can anticipate. Once you know the error code, you can use it with pragma EXCEPTION_INIT and write a handler specifically for that error.

Error O2SS0055 Incorrect EXCEPTION_INIT PRAGMA parameter

Background

Whenever you try to convert PL/SQL code having a “PRAGMA EXCEPTION_INIT” exception without defining an error number in its parameter section, SSMA generates “Error O2SS0055 Incorrect EXCEPTION_INIT PRAGMA parameter” because it doesn’t find a numeric literal. It is mandatory to pass a negative number (i.e. the error number for which you want to throw this exception) in the parameter section.

Possible Remedies

Consider the following example:

DECLARE

MYEXCEPTION EXCEPTION;

PRAGMA EXCEPTION_INIT(MYEXCEPTION, '');

BEGIN

NULL;

END;

When SSMA doesn’t find a numeric literal in the parameter section of PRAGMA EXCEPTION_INIT, SSMA generates the error “Error O2SS0055 Incorrect EXCEPTION_INIT PRAGMA parameter”.

Remediation of this error is to define an error number for which you want to throw this exception. For this, update the code as follows:

DECLARE

MYEXCEPTION EXCEPTION;

PRAGMA EXCEPTION_INIT(MYEXCEPTION, -10000);

BEGIN

NULL;

END;

SSMA will convert the updated code with no errors.

Related Errors

There are several other errors related to Exceptions that you may encounter. These include the following:

·         Error O2SS0343 FORALL statement with SAVE EXCEPTION clause is not supported

·         Error O2SS0054 Unable to convert EXCEPTION_INIT

References

For more information, check out the following references:

·         Migrating Oracle to SQL Server 2008 White Paper