Command Line Interface

Integrate SnowConvert for Teradata into your CI/CD process with the CLI version of the tool.

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

Quick start

To execute a conversion with the SnowConvert CLI you have to have an active license. Currently, the licenses for the CLI are different than the UI, but if you already have a license for the UI you should be able to reuse the same license key. In the section below we show how to install a license key.

There are several Command Line Arguments documented below, but the main ones are -i for the input folder and -o for the output folder.

Install a license

To install a license key just execute SnowConvert CLI program with the -l argument and the license key.

$: snowct -l P-ABCD-12345-EFGHI

Check license status

To install a license key just execute SnowConvert CLI program with just the -l and no other arguments.

$: snowct -l

Migrate a folder

To migrate a folder just execute SnowConvert CLI program with the -i <INPUT FOLDER> and -o <OUTPUT FOLDER> arguments.

$: snowct -i ~/Documents/Workspace/Code -o ~/Documents/Workspace/Output

CLI Arguments

Basic Conversion

-i, --input <PATH> (Required)

The path to the folder or file containing the input source code.

-o, --output <PATH> (Required)

The path to the output folder where the converted code and reports will be stored.

-a, --assessmentmode

Flag to indicate whether or not to generate only Assessment files. By default, it's set to FALSE.

--snowscript, --disableSnowScript (NO LONGER SUPPORTED)

Flags were used to indicate whether the migration tool should migrate BTEQ files, stored procedures, and macros to Snowflake Scripting.

As of Release 3.0.282. these flags are no longer supported. Please use the following flags instead:

--PLTargetLanguage

--bteqTargetLanguage

-q, --bteqTargetLanguage <TARGET_LANGUAGE>

Flags were used to indicate whether the migration tool should migrate BTEQ files to Python or SnowScript.

As of Release 4.0.92, these flags are no longer supported. Please use the following flag instead:

--scriptsTargetLanguage

-e, --encoding <CODE PAGE>

The encoding code page number is used for parsing the source files. We only accept encodings supported by .NET Core. Here are the ones supported at the moment:

Code Page

Name

Display Name

1200

utf-16

Unicode

1201D

unicodeFFFE

Unicode (Big endian)

12000

utf-32

Unicode (UTF-32)

12001

utf-32BE

Unicode (UTF-32 Big endian)

20127

us-ascii

US-ASCII

28591

iso-8859-1

Western European (ISO)

65000

utf-7

Unicode (UTF-7). Not available in .NET 5

65001

utf-8

Unicode (UTF-8). Default encoding

-m, --comments

Flag to indicate if the user wants to comment on nodes that have missing dependencies.

Target Languages

-t, --PLTargetLanguage <TARGET_LANGUAGE>

String value specifying the target language to convert Stored procedures and Macros. Currently supported are: SnowScript and JavaScript. The default value is set to SnowScript.

-p, --scriptsTargetLanguage <TARGET_LANGUAGE>

The string value specifies the target language to convert Bteq and Mload script files. Currently supported values are SnowScript and Python. The default value is set to Python.

Object Name Customization

-s, --customschema <SCHEMA_NAME>

The string value specifies the custom schema name to apply. If not specified, either PUBLIC or the original database name will be used. Example: DB1.MyCustomSchema.Table1.

If you provide this parameter with a schema named NONE --customschema none, the converted code will keep the original schema defined in the source code.

-d, --database <DB_NAME>

The string value specifies the custom database name to apply. Example: MyCustomDB.PUBLIC.Table1.

--useExistingNameQualification

This flag must be used in conjunction with the -d or -s parameters. When used, it preserves the existing name qualification from the input code when previous parameters are used. Let's take a look at this example where -s newSchema was included:

SELECT * FROM mySchema.myObject;

The same applies to databases.

--displaceDatabaseAsSchema

This flag must be used with the -s parameter. When used it will maintain Teradata's database name qualification as Snowflake's data warehouse, contrary to it's default behavior where it becomes a schema on Snowflake code. Let's look and example where -s customSchema is included:

SELECT * FROM databaseName.tableName;

Format Conversion

--CharacterToApproximateNumber <NUMBER>

An integer value for the CHARACTER to Approximate Number transformation (Default: 10).

--DefaultDateFormat <STRING>

String value for the Default DATE format (Default: "YYYY/MM/DD").

--DefaultTimeFormat <STRING>

String value for the Default TIME format (Default: "HH:MI:SS").

--DefaultTimestampFormat <STRING>

String value for the Default TIMESTAMP format (Default: "YYYY/MM/DD HH:MI:SS").

--DefaultTimezoneFormat <STRING>

String value for the Default TIMEZONE format (Default: "GMT-5").

License and Help

-l, --license [<LICENSE_KEY>]

Shows the license information. If it's followed by a license key, it will attempt to download and install such a license. For example:

  • Showing license status snowct -l

  • Installing a license snowct -l 12345-ASDFG-67890

--terms

Show license terms information.

--help

Display the help information.

Other features

--disableEWIsGeneration

Flag to indicate whether EWIs comments (Errors, Warnings, and Issues) will be generated on the converted code. The default is false.

--generateStoredProcedureTags

Flag to indicate whether the SQL statements SELECT, INSERT, CREATE, DELETE, UPDATE, DROP, MERGE in Stored Procedures will be tagged on the converted code. This feature is used for easy statement identification on the migrated code. Wrapping these statements within these XML-like tags allows for other programs to quickly find and extract them. The decorated code looks like this:

//<SQL_DELETE
EXEC(DELETE FROM SB_EDP_SANDBOX_LAB.PUBLIC.USER_LIST,[])
//SQL_DELETE!>

--replaceDeleteAllToTruncate

Flag to indicate whether Delete All statements must be replaced to Truncate or not. This will generate MSCEWI2037 when the replacement is done. Example:

Input code:

create table testTable(
    column1 varchar(30)
);

delete testTable all;

delete from testTable;

Output code (argument not specified):

CREATE TABLE PUBLIC.testTable (
column1 varchar(30)
);

DELETE FROM PUBLIC.testTable;

DELETE FROM PUBLIC.testTable ;

Output code (argument specified):

CREATE TABLE PUBLIC.testTable (
column1 varchar(30)
);

TRUNCATE TABLE PUBLIC.testTable /*** MSC-WARNING - MSCEWI2037 - DELETE ALL WAS REPLACED TO TRUNCATE, IT MIGHT BE CHANGED TO DELETE IF ACTIVITY_COUNT IS NEEDED ***/;

DELETE FROM PUBLIC.testTable ;

Learn more about how you can get access to the SnowConvert for Teradata Command Line Interface tool by filling out the form on our Snowflake Migrations Info page.

--splitPeriodDatatype

This flag is used to indicate that the tool should migrate any use of the PERIOD datatype as two separate DATETIME fields that will hold the original period begin and end values, anytime a period field or function is migrated using this flag MSCEWI2074 will be added to warn about this change.

Input Code:

CREATE TABLE myTable(
   col1 PERIOD(DATE),
   col2 VARCHAR(50),
   col3 PERIOD(TIMESTAMP)
);

Output Code (argument not specified):

CREATE TABLE PUBLIC.myTable (
   col1 VARCHAR(24) /*** MSC-WARNING - MSCEWI2053 - SNOWFLAKE DOES NOT SUPPORT THE PERIOD DATATYPE, ALL PERIODS ARE HANDLED AS VARCHAR INSTEAD ***/,
   col2 VARCHAR(50),
   col3 VARCHAR(58) /*** MSC-WARNING - MSCEWI2053 - SNOWFLAKE DOES NOT SUPPORT THE PERIOD DATATYPE, ALL PERIODS ARE HANDLED AS VARCHAR INSTEAD ***/
);

Output Code (argument specified):

CREATE TABLE PUBLIC.myTable (
   col1_begin DATE,
   col1_end DATE /*** MSC-WARNING - MSCEWI2074 - PERIOD DATA TYPES ARE HANDLED AS TWO DATA FIELDS ***/,
   col2 VARCHAR(50),
   col3_begin TIMESTAMP,
   col3_end TIMESTAMP /*** MSC-WARNING - MSCEWI2074 - PERIOD DATA TYPES ARE HANDLED AS TWO DATA FIELDS ***/
);

--arrange

Flag to indicate whether the input code should be processed before parsing and transformation.

Learn more about this step on our Processing the code page.

--RenamingFile

The path to a .json file that specifies new names for certain objects such as Tables, Views, Procedures, Functions, and Macros. This parameter can't be used with the customSchema argument. Navigate to the Renaming Feature page to learn more about this argument.

Learn more about this step on our Processing the code page.

Last updated