Top-Level Objects Report

The top level objects report provides a general overview of the main objects present in your source code.

This is a deprecated version of the SnowConvert documentation, please visit the official site HERE.

What is a "Top-Level Object"?

Top-level object is the term used to refer to the following SQL structures:

Structure	Assessment for Teradata SQL *	Assessment for Oracle SQL	Assessment for SQL Server
Table	🗸	🗸	🗸
View	🗸	🗸	🗸
Procedure	🗸	🗸	🗸
Macro	🗸	🗸	-
Join index	🗸	-	-
Sequence	-	🗸	-
Synonym	-	🗸	-
Package	-	🗸	-
Package body	-	🗸	-
Index	-	🗸	-
Database link	-	🗸	-

*Teradata currently uses a different report generation mechanism. It's planned to use the same one that Oracle and SQL Server use. For this reason, more accurate information for Teradata reports can be found here.

Where can I find it?

The top level 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 "TopLevelObjects" so it can easily be located.

The format of the file is .CSV.

What information does it contain?

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

Column	Description
PartitionKey	The unique identifier of the conversion.
FileType	The type of the file that the object is in. (SQL, BTEQ, etc...)
ObjectName	The simple name of the object itself.
HighLevelObject	The full name of the top level object that this object belongs to.
ObjectDB	The name of the database or schema that this object belongs to. This may vary between languages. Please check here the possible outputs.
FileName	The name of the file in which the object is located. Uses the relative path starting from the input directory.
LineNumber	The line number inside the file where the object is located.
LinesOfCode	The total lines of code that the object has.
ConversionStatus	The final status of the conversion of the object.
ConversionPercentage	The conversion percentage of the object.
EWIsNumber	The amount of EWIs found within the object.
HighestEWISeverity	The highest EWI severity found within the object.
EWIs	The descriptions of all the EWIs found within the object.
UDFsUsed	The names of all the user defined functions found within the object.
DeploymentOrder	The deployment order of the object regarding the other objects in the same file.
Object Id	The full qualified name of the top-level object used to uniquely identify it.

ObjectDB column variation by language

Since all the DBMS handles the object hierarchy differently, the ObjectDB column will be filled according to the input and language.

Please check the following tables which show the different combinations based on the qualified names.

Teradata

Hierarchy used: Database -> Object

Input qualified name	ObjectDBName
Database1.Procedure1	Database1
Procedure1	Undefined DB name

Oracle

Hierarchy used: Database -> Schema -> Package -> Object

Input qualified name	ObjectDBName
Database1.Schema1.Procedure1	Database1.Schema1.<NoPackage>
Schema1.Procedure1	<NoDB>.Schema1.<NoPackage>
Procedure1	<NoDB>.<NoSchema>.<NoPackage>
Database1.Schema1.Package1.Procedure1	Database1.Schema1.Package1
Schema1.Package1.Procedure1	<NoDB>.Schema1.Procedure1
Package1.Procedure1	<NoDB>.<NoSchema>.Package1

SQL server

Hierarchy used: Server -> Database -> Schema -> Object

Input qualified name	ObjectDBName
Server1.Database1.Schema1.Procedure1	Server1.Database1.Schema1
Database1.Schema1.Procedure1	<NoServer>.Database1.Schema1
Schema1.Procedure1	<NoServer>.<NoDB>.Schema1
Procedure1	<NoServer>.<NoDB>.<NoSchema>

DB2

Hierarchy used: Database -> Schema -> Object

Input qualified name	ObjectDBName
Database1.Schema1.Procedure1	Database1.Schema1
Schema1.Procedure1	<NoDB>.Schema1
Procedure1	<NoDB>.<NoSchema>

Oracle