This Snap allows you to execute arbitrary SQL.
...
| Note |
|---|
| You can drop your database with it, so be careful. |
Snap type: | Write
|
|---|
Description: |
|---|
| Prerequisites: | [None]
|
|---|
| Support and limitations: |
|
|---|
| Account: | This Snap uses account references created on the Accounts page of SnapLogic Manager to handle access to this endpoint. See PostgreSQL Account for information on setting up this type of account. |
|---|
| Views: |
| Input | This Snap allows zero or one input views. If the input view is defined, then the where clause can substitute incoming values for a given expression. |
|---|
| Output | This Snap allows zero or one output view and produces documents in the view. |
|---|
| Error | This Snap has at most one error view and produces zero or more documents in the view.
Note: Database Write Snaps output all records of a batch (as configured in your account settings) to the error view if the write fails during batch processing. |
|---|
|
|---|
Settings |
|---|
Label
| Required.The name for the Snap. You can modify this to be more specific, especially if you have more than one of the same Snap in your pipeline. |
|---|
SQL statement
| Required.Specifies the SQL statement to execute on the server.
There are two possible scenarios that you encounter when working with SQL statements in SnapLogic. You must understand the following scenarios to successfully execute your SQL statements:
Scenario 1: Executing SQL statements without expressions
If the expression toggle of the SQL statement field is not selected:
- The SQL statement must not be within quotes.
- The $<variable_name> parts of the SQL statement are expressions. In the below example, $id and $book.
For example:
.png?version=1&modificationDate=1489886486706&cacheVersion=1&api=v2) Image Modified
Additionally, the JSON path is allowed only in the WHERE clause. If the SQL statement starts with SELECT (case-insensitive), the Snap regards it as a select-type query and executes once per input document. If not, it regards it as write-type query and executes in batch mode.
Scenario 2: Executing SQL queries with expressions
If the expression toggle of the SQL statement field is selected:
- The SQL statement must be within quotes.
- The + $<variable_name> + parts of the SQL statement are expressions, and must not be within quotes. In the below example, $tablename.
- The $<variable_name> parts of the SQL statement is bind parameter and must be within quotes. In the below example, $id and $book.
| Note |
|---|
| Table name and column names must not be provided as bind parameters. Only values can be provided as bind parameters. |
For example:
 Image Modified
Known issue: When the SQL statement property is an expression, the pipeline parameters are shown in the suggest, but not the input schema.
| Note |
|---|
The non-expression form uses bind parameters, so it is much faster than executing N arbitrary SQL expressions. |
| Warning |
|---|
With the SQL statement property set as an expression, the Snap can be exposed to SQL injection. Please use this feature with caution. |
Default value: [None]
|
|---|
Pass through
| If selected, the input document will be passed through to the output view under the key 'original'. This property applies only to the Execute Snaps with SELECT statement. Default value: Selected
|
|---|
Ignore empty result
| If selected, no document will be written to the output view when a SELECT operation does not produce any result. If this property is not selected and the Pass through property is selected, the input document will be passed through to the output view. Default value: Not selected
|
|---|
Execute during preview
| Enables you to execute the Snap during the Save operation so that the output view can produce the preview data. Default value: Not selected |
|---|
| Snap History |
|---|
4.6- Enhanced to fully support SQL statements with/without expressions & SQL bind variables.
- Resolved an issue in PostgreSQL Execute Snap with array type returned a valid output but failed to validate (show the Snap as red).
|
