Missing Objects Report

The missing objects report provides a general overview of the missing objects referenced in the main objects of your source code.

PreviousIssues Report NextObject References Report

Last updated 8 months ago

What is a "Missing Object"?

Missing object is the term used to refer to missing DDL definitions inside the source code that are being referenced by code units. The table below shows which elements could be missing objects in each supported language.

Object

Teradata

Oracle

SQL Server

If an asterisk ('*') is listed in the section above, it means that the object is used to call properties from itself that are not considered DDL statements such as constants, variables, or cursors.

Where can I find it?

The missing objects report can be found in a folder named "reports", in the output folder of your conversion. The name of the file itself starts with "MissingObjectReferences" so it can easily be located.

The format of the file is .CSV.

What information does it contain?

The missing objects report contains the following information about all the missing objects found while converting:

Known Issues

Variables defined in shell files used in script files like .bteq are considered missing objects because their definition is not part of the input files that SnowConvert processes. E.g. the myDB variable is defined in the shell file but this is a file that is not part of the input for SnowConvert. Only the .bteq file will be processed and therefore, line 5 will be marked as a missing reference.

myShellFile.sh

export myDB=exampleDatabase
bteq < example.bteq

example.bteq

```
.LABEL EX_SQE

create multiset volatile table DR as
   select * from ${myDB}.myTable;
```

Preprocessing an Oracle workload by splitting packages can result in extra missing references if the package's schema is not specified in the extracted objects.

Original Code

Original Package.sql

CREATE package Schema1.Package1
IS
  CREATE TABLE Table1 (
    col1 INTEGER
  );
  
  CREATE PROCEDURE Proc1
    BEGIN
      SELECT * FROM Schema1.Table1;
    END

END

Notice that in this case, Table1 is automatically created within the schema Schema1, so the reference in line 9 resolves correctly. However, if a package split process is executed prior to the migration and the resulting files are like these ones:

Modified Code after a package split process

Schema1_Table1.sql

  CREATE TABLE Table1 (
    col1 INTEGER1
  );

Schema1_Proc1.sql

CREATE PROCEDURE Proc1
    BEGIN
        SELECT * FROM Schema1.Table1;
    END

The reference on line 3 of the file Schema1_Proc1.sql will be marked as a missing reference, because Table1 was not explicitly created within the schema Schema1.