Procedures

This section documents the transformation of the syntax and the procedure's TSQL statements to snowflake java script

Some parts in the output code are omitted for clarity reasons.

1. CREATE PROCEDURE Translation

Snowflake CREATE PROCEDURE is defined in SQL Syntax whereas its inner statements are defined in JavaScript.

Source Code:

IN -> SqlServer_01.sql
-- Additional Params: -t JavaScript
CREATE PROCEDURE HumanResources.uspGetAllEmployees
     @FirstName NVARCHAR(50),
     @Age INT
AS
    -- TSQL Statements and queries...
GO

Translated Code:

OUT -> SqlServer_01.sql
CREATE OR REPLACE PROCEDURE HumanResources.uspGetAllEmployees (FIRSTNAME STRING, AGE INT)
RETURNS STRING
LANGUAGE JAVASCRIPT
COMMENT = '{"origin":"sf_sc","name":"snowconvert","version":{"major":1, "minor":0},{"attributes":{"component":"transact"}}'
EXECUTE AS CALLER
AS
$$
    // SnowConvert Helpers Code section is omitted.
$$;

Parameter's DATA TYPE

Parameters data types are being translated to Snowflake equivalent. See also Data Types.

EXEC helper

In order to be able to run statements from a procedure in the SnowFlake environment, these statements have to be preprocessed and adapted to reflect their execution in several variables that are specific to the source language.

SnowConvert automatically translates the supported statements and makes use of an EXEC helper. This helper provides access and update capabilities to many variables that simulate how the execution of these statements would be in their native environment.

For instance, you may see that in the migrated procedures, there is a block of code that is always added. We are going to explain the basic structure of this code in the next section. Please keep in mind that we are always evaluating and searching for new and improved ways to streamline the transformations and any helper that we require.

Structure

The basic structure of the EXEC helper is as follows:

  1. Variable declaration section: Here, we declare the different variables or objects that will contain values associated with the execution of the statements inside the procedure. This includes values such as the number of rows affected by a statement, or even the result set itself.

  2. fixBind function declaration: This is an auxiliary function used to fix binds when they are of Date type.

  3. EXEC function declaration: This is the main EXEC helper function. It receives the statement to execute, the array of binds (basically the variables or parameters that may be modified by the execution and require data permanence throughout the execution of the procedure), the noCatch flag that determines if the ERROR_HANDLERS must be used, and the catchFunction function for executing custom code when there's an exception in the execution of the statement. The body of the EXEC function is very straightforward; execute the statement and store every valuable data produced by its execution, all inside an error handling block.

  4. ERROR VARS: The EXEC catch block sets up a list of error variables such as MESSAGE_TEXT, SQLCODE, SQLSTATE, PROC_NAME and ERROR_LINE that could be used to retrieve values from user defined functions, in order to emulate the SQL Server ERROR_LINE, ERROR_MESSAGE, ERROR_NUMBER, ERROR_PROCEDURE and ERROR_STATE built in functions behavour. After all of these variables are set with one value, the UPDATE_ERROR_VARS user defined function, will be in charge of update some environment variables with the error values, in order to have access to them in the SQL scope.

Code

The following code block represents the EXEC helper inside a procedure:

Simple EXEC example

This is a simple example of an EXEC call inside a Stored Procedure

Source Code

Expected code

EXEC within a Store Procedure with a parameter

In this example, the EXEC command is inside a Stored Procedure and receives a parameter value

Source Code

Expected Code

EXEC invoking a Store Procedure with a parameter

In this example, the EXEC invokes another Stored Procedure and pass adds a parameter

Source Code

Expected Code

Parameters with Default Value.

In SqlServer, there can be parameters with a default value in case these are not specified when a procedure is being called.

For example

In Snowflake is translated to

CURSOR helper

Insert Into EXEC Helper

The Insert into Exec helper generates a function called Insert insertIntoTemporaryTable(sql). This function will allow the transformation for INSERT INTO TABLE_NAME EXEC(...) from TSQL to Snowflake to imitate the behavior from the original statement by inserting it's data into a temporary table and then re-adding it into the original Insert.

For more information on how the code for this statement is modified look at the section for Insert Into Exec

This Generated code for the INSERT INTO EXEC, may present performance issues when handling EXECUTE statements containing multiple queries inside.

LIKE Helper

In case that a like expression is found in a procedure, for example

Since the inside of the procedure is transformed to javascript, the like expression will throw an error. In order to avoid and keep the functionality, a function is added at the start of the procedure if a like expression is found.

With this function, we can replicate the functionality of the like expression of sql. Let's see the diferent cases that it can be used

In the last code, there is a normal like a not like, and a like with escape. The transformation will be

Note that the likes are transformed to function calls

The parameters that the function LIKE receive are the followings:

  • The expression that is being evaluated.

  • The pattern of comparison

  • If it is present, the escape character, this is an optional parameter.

Select Helper

Generates a function called SELECT when a scalar value has to be set to a variable

In this case, it will generate the following code with the SELECT helper

The SELECT helper could be used as well to insert into a local value a retrieved value from a query. The helper was designed specifically to support the same behavour of the SQL Server SELECT @local_variable. The args parameter, represents each operation applied to all of the local variables inside the select. See also SELECT @Variable. For example:

In this case the variable assignments will be translated to JavaScript lambdas in order to emulate the SQL Server behavior.

RAISERROR Helper

This helper is generated when there exists usages of a RAISERROR call in the source code. Example:

The RAISERROR executes the UPDATE_ERROR_VARS_UDF in order to store the value of the error message, severity and state as environment variables, in case they need to be used by calling any of the ERROR built in functions. Finally, the error message is thrown with the same format as SQL Server does.

Identity Function Helper

This helper is generated whenever the Identity Fuction is used on a Select Into inside a procedure.

The parameters for this helper are the same as the original function, it is created in order to generate a sequence to mimic the identity function behavior in TSQL, the changes to the original code are:

  • An additional method call to the IdentityHelper function using the same parameters found in the source code.

  • And call to the IDENTITY_UDF a function design to get the next value in the sequence.

Just like in the TSQL if no parameters are given (1,1) will be the default values.

CALL Procedure Helper

This helper is generated whenever there is a call to what previously was a user defined function, but is now a procedure as a result of the translation process.

The purpose of this helper is to encapsulate the logic required for calling procedures as if they were functions.

Please keep in mind that this functionality is limited, since procedures cannot be invoked within queries such as SELECT.

Example of use, assuming that FooSelfAssign(@PAR INT) was translated to a procedure:

Note that the translation for VAR1 is very straightforward, but for VAR4, the outmost CALL contains a list with the rest of the CALLs, as bindings.

Each successive CALL is translated to a binding, if it's contained within another CALL.

2. Variables

DECLARE @Variable

Source Code

Translated Code

DECLARE @Variable Table

In this case, the DECLARE is used to declare a variable table, let's see an example.

If we execute that code in Sql Server, we will get the following result

Now, let's see the transformation in Snowflake

Note that from the lines 61 to 67 are the results of those statements inside the procedure.

The Declare Variable Table is turned into a Temporary Table. Note that the name, which that in the name the character @ was replaced for T_.

If we execute that code in Snowflake, we will not get any result. it will display just null. That's because that last Select is now in the EXEC helper. So, how do we know that the table is there?

Since it was created as a temporary table inside the Procedure in an EXEC, we can do a Select to that table outside of the Procedure.

If we execute that statement, we will get the following result

SET @Variable

For now, the Set Variable is transformed depending on the expression that is has on the right side.

If the expression has a transformation, it will be transformed to it's JavaScript equivalent.

Example

Translated Code

As you can see in the example, the value of the variable NOTSUPPORTED is commented since it is not being transformed for the time being. Note that means that the transformation is not completed yet.

Other kinds of sets are commented, for example the following

Translated Code

SELECT @Variable

For now, the SELECT @variable is being transformed into a simple select, removing the variable assignations, and keeping the expressions at the right side of the operator. The assignment operations of the local variables in the select, will be replaced with arrow functions that represent the same behavour of the operation being did during the local variable assignment in SQL Server.

Input

Output

3. Statements translation

SELECT

Basic form

The basic SELECT form does not have bindings, so the translation implies the creation of a call to the EXEC helper function, with one parameter. For example:

IF

Source Code

Translated Code

WHILE

Source Code

Translated Code

EXEC / EXECUTE

Source code

Translated Code

THROW

The transformation for THROW ensures that the catch block that receives the error has access to the information specified in the original statement.

For instance:

Will be transformed to:

RAISERROR

SQL Server RAISERROR function is not supported in Snowflake. SnowConvert identifies all the usages in order to generate a helper that emulates the original behavour. Example:

From

To

BREAK/CONTINUE

The break/continue transformation, ensures flow of the code to be stopped or continue with another block.

For instance:

Will be transformed to:

INSERT INTO EXEC

The code is modify slightly due to the INSERT INTO [Table] EXEC(...) Statement not being supported in Snowflake this allows us to replicate the behavior by adding a few lines of code:

  • The first line added is a call to the insertIntoTemporaryTable to where the extracted code from the argument inside the EXEC, this will Insert the result set into a Temporary table. For more information on the function check the Insert Into EXEC Helper section.

  • The Insert's Exec is removed from the code and a query retrieving the results of the EXEC from the temporary table.

  • The last line added is a DROP TABLE statement for the Temporary Table added.

Source Code:

Translated Code:

BEGIN TRANSACTION

BEGIN TRANSACTION is transformed to Snowflake's BEGIN command, and inserted into an EXEC helper call.

The helper is in charge of actually executing the resulting BEGIN.

Example:

COMMIT TRANSACTION

COMMIT TRANSACTION is transformed to Snowflake's COMMIT command, and inserted into an EXEC helper call.

The helper is in charge of actually executing the resulting COMMIT.

Example:

ROLLBACK TRANSACTION

ROLLBACK TRANSACTION is transformed to Snowflake's ROLLBACK command, and inserted into an EXEC helper call.

The helper is in charge of actually executing the resulting ROLLBACK .

Example:

WAITFOR DELAY

WAITFOR DELAY clause is transformed to Snowflake's SYSTEM$WAIT function. The time_to_pass parameter of the DELAY is transformed to seconds, for usage as a parameter in the SYSTEM$WAIT function.

The other variants of the WAITFOR clause are not supported in Snowflake, and are therefore marked with the corresponding message.

Example:

3. Cursors

Since CURSORS are not supported in Snowflake, SnowConvert maps their functionality to a JavaScript helper that emulates the original behavior in the target platform. Example:

Input:

Output:

DECLARE CURSOR

For now, the Declare Cursor is just being commented.

Source Code

Translated Code

OPEN

Source Code

Translated Code

FETCH

Source Code

Translated Code

CLOSE

Source Code

Translated Code

DEALLOCATE

Source Code

Translated Code

@@FETCH_STATUS

Source Code

Translated Code

@@CURSOR_ROWS

Source Code

Translated Code

4. Expressions

Binary Operations

Source Code

Translated Code

Conditionals

Source Code

Translated Code

IN Predicate

NULL Predicate

Source Code

Translated Code

5. Labels and Goto

Labels have not the same behavior in JavaScript as SQL Server has. To simulate the behavior, they are being transformed to functions . Its usage is being replaced with a call of the generated function that contains all the logic of the label. Example:

Source Code

Translated Code

As you see in the example above, the function declarations that were the labels in the source code, will be put at the end of the code in order to make it cleaner.

GOTO is another command that does not exist in JavaScript. To simulate its behavour, their usages are being transformed to calls to the function (label) that is referenced, preceded by a return statement. Example:

Source Code

Translated Code

As you see in the example above, the return is added to the function call, in order to stop the code flow as SQL Server does with the GOTO .

  1. SSC-EWI-0038: This statement may be a dynamic SQL that could not be recognized and converted.

  2. SSC-EWI-0040: Statement Not Supported.

  3. SSC-EWI-0073: Pending Functional Equivalence Review.

Last updated