Procedures
This section documents the transformation of the syntax and the procedure's TSQL statements to snowflake java script
1. CREATE PROCEDURE Translation
Snowflake CREATE PROCEDURE is defined in SQL Syntax whereas its inner statements are defined in JavaScript.
Source Code:
-- Additional Params: -t JavaScript
CREATE PROCEDURE HumanResources.uspGetAllEmployees
@FirstName NVARCHAR(50),
@Age INT
AS
-- TSQL Statements and queries...
GOTranslated Code:
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:
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.
fixBind function declaration: This is an auxiliary function used to fix binds when they are of Date type.
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.
ERROR VARS: The EXEC catch block sets up a list of error variables such as
MESSAGE_TEXT,SQLCODE,SQLSTATE,PROC_NAMEandERROR_LINEthat 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, theUPDATE_ERROR_VARSuser 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
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
insertIntoTemporaryTableto where the extracted code from the argument inside theEXEC, 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 .
Related EWIs
SSC-EWI-0038: This statement may be a dynamic SQL that could not be recognized and converted.
SSC-EWI-0040: Statement Not Supported.
SSC-EWI-0073: Pending Functional Equivalence Review.
Last updated