SnowConvert AI - Teradata - DDL¶
In this section, you will find the documentation for the translation reference of Data Definition Language Elements.
Index¶
Translation reference to convert INDEX statement to Snowflake
Warning
Currently, Create Index statement is not being converted but it is being parsed. Also, if your source code has Create index statements, these are going to be accounted for in the Assessment Report.
Example of Create Index
Teradata input¶
Note
Due to architectural reasons, Snowflake does not support indexes so, SnowConvert AI will remove all the code related to the creation of indexes. Snowflake automatically creates micro-partitions for every table that help speed up the performance of DML operations, the user does not have to worry about creating or managing these micro-partitions.
Usually, this is enough to have a very good query performance however, there are ways to improve it by creating data clustering keys. Snowflake’s official page provides more information about micro-partitions and data clustering.
Join Index¶
Description ¶
In SnowConvert AI, Teradata Join Indexes are transformed into Snowflake Dynamic Tables. To properly configure Dynamic Tables, two essential parameters must be defined: TARGET_LAG and WAREHOUSE. If these parameters are left unspecified in the configuration options, SnowConvert AI will default to preassigned values during the conversion, as demonstrated in the example below.
For more information, see the Teradata Join Indexes documentation.
For details on the necessary parameters, see the Snowflake CREATE DYNAMIC TABLE documentation.
Sample Source Patterns¶
Teradata
Join Index
Snowflake
Dynamic Table
Known Issues¶
No known errors detected at this time.
Schema¶
Description ¶
The translation of the CREATE SCHEMA statement from Teradata to Snowflake is simple, as the basic syntax remains the same.
Sample Source Patterns¶
Teradata
Join Index
Snowflake
Dynamic Table
Known Issues¶
WITH Properties of CREATE SCHEMA¶
The WITH properties associated with the CREATE SCHEMA statement in Teradata are not supported in Snowflake, as there is no equivalent functionality available.
Teradata
Join Index
Snowflake
Dynamic Table
Related EWIs¶
SSC-EWI-0073: Pending Functional Equivalence Review.
Views¶
Translation reference to convert Teradata VIEW statement to Snowflake
Note
Some parts in the output code are omitted for clarity reasons.
Description ¶
Teradata’s VIEW statement is translated to Snowflake VIEW syntax.
For more information, see the Teradata VIEW documentation.
Sample Source Patterns¶
Create View Transformation¶
Teradata
View¶
Snowflake
View¶
Custom Schema Tag¶
The custom schema is specified in the comment section before the specification of the view, with an XML tag named “sc-view” that contains only the value of the schema and the view name separated with a period ‘.’ as shown below: <sc-view>SCHEMANAME.VIEWNAME</sc-view>
The custom schema will be used as a view qualifier, and then the name of the view and all the objects referred to in the FROM queries and inner queries will be using that custom schema. Therefore could be several views with the same name, but with different custom tags. Example: two views with the same name, will take the custom schema tag information to perform the translation.
Teradata¶
View¶
Snowflake¶
The transformation for Snowflake will vary depending on the customized schema name MySchema, customized database name MyDatabase or not selecting a customized database or schema in the conversion settings.
Custom Schema¶
Custom Database¶
Non selected¶
Known Issues¶
1. Locking row for access logic difference¶
In Snowflake, access to objects and elements is based on users and privileges.
Related EWIs¶
SSC-FDM-0007: Element with missing dependencies.
SSC-FDM-0019: Semantic information could not be loaded.
Tables¶
Translation reference to convert Teradata TABLE statement to Snowflake
Note
Some parts in the output code are omitted for clarity reasons.
Description ¶
Teradata’s TABLE statement is translated to Snowflake TABLE syntax.
For more information, see the Teradata CREATE TABLE documentation.
Sample Source Patterns¶
Simple Create Table¶
Teradata
Table¶
Snowflake
Table¶
Table Kind Clause - SET and MULTISET¶
Teradata’s kind clause determines whether duplicate rows are permitted (MULTISET) or not (SET).
Teradata¶
Table¶
Snowflake¶
Table¶
Volatile and Global Temporary Tables¶
Teradata’s Volatile and Global Temporary tables are used for the temporary storage of data. Their difference lies in that the table definition (DDL) of Global Temporary tables is persisted in the Data Dictionary, while Volatile tables definition is not stored.
Teradata¶
Table¶
Snowflake¶
Table¶
With data and with no data option¶
Teradata
Table¶
Snowflake
Table¶
Snowflake’s Reserved & Limited Keywords¶
SnowConvert AI facilitates seamless SQL migrations to Snowflake by addressing challenges associated with reserved keywords. As per Snowflake’s reserved and limited keyword documentation, certain keywords cannot be used as column names, table names, or aliases without special handling. SnowConvert AI includes functionality to ensure SQL code compatibility in such cases.
Reserved ANSI Keywords as Column Names
For column names that match ANSI or Snowflake reserved keywords, SnowConvert AI automatically wraps the column name in double quotes (") to comply with Snowflake’s syntax rules. This adjustment ensures that queries with these column names compile correctly in Snowflake without requiring manual intervention.
Example:
Table¶
Snowflake
Table¶
Snowflake-Specific Reserved Keywords
Columns that match Snowflake-specific reserved keywords (for example, CONSTRAINT, CURRENT_DATE, CURRENT_TIME) may still cause compilation issues even when wrapped in quotes. SnowConvert AI detects these instances and generates a warning with code SSC-EWI-0045, prompting users to review and potentially rename these columns for compatibility.
Example:
Table¶
Snowflake
Table¶
Known Issues¶
1. Create table options not supported¶
As shown in the example “Simple Create Table”, Snowflake does not support Teradata create table options. They are removed.
2. Partition by performance issues¶
In the example “Simple Create Table”, the partition by statement is removed due to performance considerations.
3. Primary Index moved¶
In Teradata, the primary index constraint is declared outside of the create table statement, but in Snowflake it is required to be inside, as shown in the example “Simple Create Table”.
4. SET semantics not supported¶
As shown in the example “Table Kind Clause - SET and MULTISET”, Snowflake does not support Teradata’s SET semantics. They are removed.
5. Global Temporary table option not supported¶
As shown in the example “Volatile and Global Temporary Table”, Snowflake does not support Teradata’s Global Temporary table option. It will be removed.
6. Compress unsupported¶
COMPRESS (value1. value2, value3) is removed due to being unsupported.
7. On commit unsupported¶
On commit is removed due to being unsupported.
8. Block compression unsupported¶
Block compression is removed due to being unsupported.
9. Normalize unsupported¶
Normalize is removed due to being unsupported.
Related EWIs¶
SSC-FDM-0009: GLOBAL TEMPORARY TABLE functionality not supported.
SSC-FDM-0019: Semantic information could not be loaded.
SSC-FDM-TD0024: Set table functionality not supported.
SSC-PRF-0007: CLUSTER BY performance review.
SSC-EWI-0045: Column Name is Snowflake Reserved Keyword.
WITH DEFAULT¶
Translation reference to convert Teradata WITH DEFAULT clause in column definitions to Snowflake
Note
Some parts in the output code are omitted for clarity reasons.
Description ¶
Teradata’s WITH DEFAULT clause sets a system-default value to columns that are inserted with no values. This value is typically the equivalent of zero or empty.
Syntax:¶
The following table shows Teradata’s data types, their corresponding type in Snowflake, and the default value to be set if supported.
| Teradata | Snowflake | Default Value |
|---|---|---|
| BLOB[(n)] | BYTE | NOT SUPPORTED |
| BYTE[(n)] | BYTE | NOT SUPPORTED |
| VARBYTE[(n)] | BYTE | NOT SUPPORTED |
| BIGINT | BIGINT | 0 |
| BYTEINT | BYTEINT | 0 |
| DECIMAL [(n[,m])] | DECIMAL | 0 |
| DOUBLE PRECISION | DOUBLE PRECISION | 0 |
| FLOAT | FLOAT | 0 |
| INTEGER | INTEGER | 0 |
| NUMBER(n[,m]) | NUMBER | 0 |
| NUMBER[(*[,m])] | NUMBER | 0 |
| NUMERIC [(n[,m])] | NUMERIC | 0 |
| REAL | REAL | 0 |
| SMALLINT | SMALLINT | 0 |
| DATE | DATE | CURRENT_DATE |
| TIME [(n)] | TIME | CURRENT_TIME |
| TIMESTAMP [(n)] | TIMESTAMP | CURRENT_TIMESTAMP |
| TIMESTAMP WITH TIME ZONE | TIMESTAMP_TZ | LOCALTIMESTAMP |
| INTERVAL DAY [(n)] | VARCHAR(21) | '0DAY' |
| INTERVAL DAY [(n)] TO HOUR | VARCHAR(21) | '0DAY' |
| INTERVAL DAY [(n)] TO MINUTE | VARCHAR(21) | '0DAY' |
| INTERVAL DAY [(n)] TO SECOND | VARCHAR(21) | '0DAY' |
| INTERVAL HOUR [(n)] | VARCHAR(21) | '0HOUR' |
| INTERVAL HOUR [(n)] TO MINUTE | VARCHAR(21) | '0HOUR' |
| INTERVAL HOUR [(n)] TO SECOND | VARCHAR(21) | '0HOUR' |
| INTERVAL MINUTE [(n)] | VARCHAR(21) | '0MINUTE' |
| INTERVAL MINUTE [(n)] TO SECOND [(m)] | VARCHAR(21) | '0MINUTE' |
| INTERVAL MONTH | VARCHAR(21) | '0MONTH' |
| INTERVAL SECOND [(n,[m])] | VARCHAR(21) | '0SECOND' |
| INTERVAL YEAR [(n)] | VARCHAR(21) | '0YEAR' |
| INTERVAL YEAR [(n)] TO MONTH | VARCHAR(21) | '0YEAR' |
| CHAR[(n)] | CHAR | '' |
| CHARACTER(n) CHARACTER SET GRAPHIC | - | NOT SUPPORTED |
| CLOB | - | NOT SUPPORTED |
| CHAR VARYING(n) | VARCHAR | '' |
| LONG VARCHAR | - | NOT SUPPORTED |
| LONG VARCHAR CHARACTER SET GRAPHIC | - | NOT SUPPORTED |
| VARCHAR(n) | VARCHAR | '' |
| VARCHAR(n) CHARACTER SET GRAPHIC | - | NOT SUPPORTED |
| PERIOD(DATE) | VARCHAR(24) | NOT SUPPORTED |
| PERIOD(TIME [(n)]) | VARCHAR(24) | NOT SUPPORTED |
| PERIOD(TIMESTAMP [(n)]) | VARCHAR(24) | NOT SUPPORTED |
Sample Source Patterns¶
Teradata¶
Query¶
Snowflake ¶
Query¶
Known Issues¶
1. Unsupported types¶
As shown in the table in the description table, some types are not supported and no default value will be set when transforming the WITH DEFAULT clause.
Related EWIs¶
SSC-EWI-0021: Not Supported in Snowflake.
SSC-EWI-0036: Data type converted to another data type.
CREATE MACRO¶
Translation reference to convert Teradata CREATE MACRO to Snowflake Scripting
Description ¶
The Teradata CREATE MACRO defines one or more statements that are commonly used or that perform a complex operation, thus avoiding writing the same sequence of statements multiple times. The macro is executed when it is called by the EXECUTE statement.
For more information, see the Teradata CREATE MACRO documentation.
Sample Source Patterns ¶
Setup data¶
The following code is necessary to execute the sample patterns present in this section.
Teradata¶
Snowflake¶
Basic Macro ¶
Since there is no macro object in Snowflake, the conversion tool transforms Teradata macros into Snowflake Scripting stored procedures. Besides, to replicate the functionality of the returned result set, in Snowflake Scripting, the query that is supposed to return a data set from a macro is assigned to a RESULTSET variable which will then be returned.
Teradata ¶
Query¶
Result¶
Snowflake Scripting ¶
Query¶
Result¶
Macro Calls Another Macro ¶
SnowConvert AI supports the scenario where a macro calls another macro and, by transitivity, a result set is returned by getting the results from Snowflake’s RESULT_SCAN(LAST_QUERY_ID()).
Teradata¶
Query¶
Result¶
Snowflake Scripting ¶
Query¶
Result¶
Macro with no result set¶
Not all macros are intended to return a result set. The mentioned scenario is also supported.
Teradata¶
Query¶
Result¶
Snowflake Scripting ¶
Query¶
Result¶
Macro returns multiple result sets¶
In Teradata, macros can return more than one result set from a single macro.
Snowflake Scripting procedures only allow one result set to be returned per procedure. To replicate Teradata behavior, when there are two or more result sets to return, they are stored in temporary tables. The Snowflake Scripting procedure will return an array containing the name of the temporary tables.
Teradata¶
Query¶
Result Set 1¶
Result Set 2¶
Snowflake Scripting ¶
Query¶
Result Set 1¶
Visualize Result Sets¶
Executing the above procedure on Snowflake, an array with temporary table names in it will be returned:
[ “RESULTSET_93D50CBB_F22C_418A_A88C_4E1DE101B500”, “RESULTSET_6BDE39D7_0554_406E_B52F_D9E863A3F15C”]
It is necessary to execute the following queries to display the result sets just like in Teradata.
Query¶
Result Set 1¶
Result Set 2¶
Known Issues ¶
No issues were found.
Related EWIs¶
CREATE PROCEDURE¶
Translation reference to convert Teradata CREATE PROCEDURE to Snowflake Scripting
Description
The Teradata CREATE PROCEDURE and REPLACE PROCEDURE statement generates or replaces a stored procedure implementation and compiles it.
For more information, see the Teradata CREATE PROCEDURE and REPLACE PROCEDURE documentation.
Sample Source Patterns ¶
Setup data¶
The following code is necessary to execute the sample patterns present in this section.
Teradata¶
Snowflake¶
Basic Procedure ¶
Teradata ¶
Query¶
Result¶
Snowflake Scripting ¶
Query¶
Result¶
Single out parameter ¶
Teradata¶
Query¶
Result¶
Snowflake Scripting ¶
Query¶
Result¶
Multiple out parameter ¶
Teradata¶
Query¶
Result¶
Snowflake Scripting ¶
Query¶
Result¶
Multiple out parameter with dynamic result sets ¶
Teradata¶
Query¶
Result¶
 (1).png)
Snowflake Scripting ¶
Query¶
Known Issues ¶
1. SQL Data Access
By default, Snowflake procedures support the execution of any kind of SQL statements, including data reading or modification statements, making the SQL data access clause non-relevant. This clause will be ignored when converting the procedure.
2. Top Level Objects in Assessment Report
Elements (Temporal tables or Views) inside Stored Procedures are being counted in the Assessment report as Top Level Objects. The SnowConvert AI team is now working on a fix for this scenario.
Related EWIs¶
SSC-EWI-0073: Pending Functional Equivalence Review.
SSC-FDM-0020: Multiple result sets are returned in temporary tables.