CALL Statements and Stored Procedures

Cloud app connectors can support operations that cannot be presented as objects with SELECT/INSERT/UPDATE/DELETE operations. Examples of such operations include sending an SMS in ClickSend, copying a document in Formstack Documents, etc. Skyvia allows running such operations as stored procedures.

Skyvia presents certain features of some cloud apps as stored procedures. They can be specific operations that cannot be presented via objects and usual SELECT/INSERT/UPDATE/DELETE operations or just DML operations for objects with specifics. For example, such operations like sending an SMS in or campaign

You can find the list of supported stored procedures for a connector in the documentation of the corresponding connector.

Using CALL Statements

You can use CALL SQL statements against cloud apps to run stored procedures. You can use them in the same tools as any other supported SQL statement. However, there is no point to call them when Skyvia expects SQL statement to return data, because stored procedures in cloud app connectors do not return any data. They only perform DML or other operations in the data source.

For example, it is not recommended to call them in:

Besides, using stored procedures in some of these places could lead to undesired stored procedure calls when designing the integration.

Stored Procedure Parameters

Stored procedures have parameters of different data types. Some parameters are required. This means that you must specify non-null values for them, otherwise the stored procedure call will fail. Others are optional (not required), and you may specify null values for them. However, even if a parameter is optional, you cannot omit it in the CALL statement at all.

CALL Statement Example

Here is an example of calling a stored procedure that copies a document in Formstack Documents:

1
call CopyDocument(903384,'Cloned Document')