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:
- Export and Import tasks, in the Advanced mode of the task editor
- Data Flow Source and Lookup components
Besides, using stored procedures in some of these places could lead to undesired stored procedure calls when designing the integration package.
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')