Invantive SQL v2.0 Grammar

sqlBatch:

Compatibility

The Invantive implementation of SQL is based upon ANSI SQL, extended by aspects from popular SQL implementations such as PostgreSQL, MySQL, Oracle, Teradata and Microsoft SQL Server. It is topped of with Invantive-specific extensions, especially for procedural SQL, distributed SQL and distributed transactions. The basis is to implement functions such that as little as possible changes are necessary to run a SQL statement originating from another SQL implementation on Invantive SQL. For instance, to retrieve the current time you can use 'sysdate', 'now', 'getdate()' and 'sysdatetime' to name a few. The same holds for the procedural extension Invantive Procedural SQL, which reflects SQL/PSM and makes it easy to port Oracle PL/SQL or PostgreSQL PL/pgSQL statements.

Distributed SQL, Databases and Data Containers

It is easy to exchange and/or combine data across the supported platforms with data. To each platform (such as Salesforce or Exact Online Belgium) multiple connections can be active with the same or different platform-specific connection settings. Each open connection to a platform is named a 'data container'.

All opened connections together are named a 'database'.

When multiple data containers have been opened, each one has an alias to refer it by in Invantive SQL statements. For instance, a connection can be open for two different customer accounts on Exact Online Netherlands aliased as 'eolnl_comp1' and 'eolnl_comp55') and one for an Exact Online Belgium custom, aliased as 'eolbe_my_new_company'. The aliases can be freely chosen as long as they are valid identifiers and defined in the databases configuration file 'settings.xml'.

Service Providers

A number of special connections are always made, each of which can occur at most once. These are the 'service providers' such as:

• 'datadictionary': metadata of the current database, such as list of tables and executed SQL statements performance.
• 'os': information on the operating system running the SQL engine, such as reading file contents.
• 'smtp': synchronously send mails through SMTP.

Partitioning

Especially online platforms have a multi-tenant structure, in which the data is partitioned per customer, company or person. When the data model is identical across tenants, Invantive SQL considers them 'partitions'. SQL statements can run across multiple or one partitions, often in parallel. This enables consolidation scenarios across partitions (such as Exact Online or Nmbrs companies) as well as high-performance in MPP environments.

The partitions to be used can be specified with the 'use' statement, either through an explicit list of partitions to be selected across data containers, or through a SQL select statement returning the list of partitions to use. Please note that although the 'use' statement resembles the 'use DATABASE' statement on Microsoft SQL Server or PostgreSQL you can on Invantive SQL have multiple partitions active at the same time in one user session.

Identifiers

For identifiers, the regular conventions hold for the set of allowed characters. Depending on the platform, the identifiers are case sensitive or not. In general, it is best to assume that the identifier are case insensitive. There is no length limit on an identifier imposed by Invantive SQL.

Procedural SQL

Invantive Procedural SQL (or "PSQL" for short) is a procedural extension on top of Invantive SQL. It is based on the ISO-standard 9075-4:2016 (SQL/PSM) and extends Invantive SQL with procedural options like blocks, variables, conditional execution and loops. The procedural code is - together with the Invantive SQL contained - as a whole into pseudo-code and then executed.

The procedural code does not lean on the procedural options of the platforms being used, so it is easy to retrieve and change data in all supported cloud, file and database platforms. The pre-compiled procedural code does not perform context switches between procedural and SQL logic.

Licensing

Features

The available functionality of Invantive SQL features is based upon the license features. For instance the free implementation of Invantive SQL is limited to 1.000 rows and no access to group functions. Please consult the data dictionary contents for your license features.

Usage Fees

For paid products, the fee depends on a number of factors: users, devices, billable partitions. All fees depend on actual use. Additionally, the number and volume in KB of reads and writes is registered to enable communication with the platform partners on the performance of their platform.

A rough estimate is that the billable partitions reflect the product of number of legal entities times number of source systems. The number of billable partitions is determined as follows, where using twice or more often the same billable partition doesn't influence the number:

• Accessing a provider which does not have a concept of "partition" count as 1 partition per different connection. A so-called data container ID is determined which reflects the backend connected to. For instance, connectiong to my-ftp-host.com and another-ftp-host.com counts as two partitions. Examples of such providers are FTP, SQL Server and cbs.nl.
• Accessing a provider which has a concept of "partition" count as the number of partitions used during the connection. For instance, using the Exact Online company 234 and 456 counts as two partitions. Examples of such providers are Exact Online, NMBRS, Loket and XML Audit File Financieel.
• Accessing data through xmltable, csvtable, jsontable and exceltable counts as the number of different parameter combination used. For instance, accessing an Excel range 'Sheet1' and a named range 'mydata' counts as two partitions.

settings.xml

The file settings.xml defines for a user or program the list of defined databases. Databases are grouped in 'database groups' for visual display. Database groups have no further functionality. Each database consists of one or multiple data containers.

The file 'settings.xml' is most often found on Microsoft Windows in your '%USERPROFILE%\invantive' folder, such as 'c:\users\john.doe\invantive\settings.xml'. It is shared across all Invantive SQL product installations for the user.

There are many scenarios to share database specifications across a user community, such as WAN-scenarios with Invantive Web Service, large corporate scenarios using DNS-entries as well as file shares, included files as well as single user solutions. Please involve a consultant when you want to deploy across thousands of users or more.

For user communities of up to 10 users, we recommend that company-specific settings are grouped per role in a separate file named 'settings-ROLE.xml' and placed in the default folder. Invantive SQL will automatically merge these files in the main settings.xml file.

Group Functions

The Invantive implementation of SQL is based upon ANSI SQL, extended by aspects from popular SQL implementations such as PostgreSQL, MySQL, Oracle, Teradata and Microsoft SQL Server. It is topped of with Invantive-specific extensions, especially for distributed SQL and distributed transactions. The basis is to implement functions such that as little as possible changes are necessary to run a SQL statement originating from another SQL implementation on Invantive SQL. For instance, to retrieve the current time you can use 'sysdate', 'now', 'getdate()' and 'sysdatetime' to name a few.

Popular group functions such as 'stddev' are available. However, currently you can not combine in one unnested SQL statement both group functions as well as expressions on the variables. In that case use an inner (nested) SQL statement to apply the expressions on the data, and execute the group functions in the outer SQL statement with the syntax 'select group() from ( select ... from ... )'.

Locking

An Invantive SQL statement can work with many traditional and online platforms. There are no locking features on data and objects, since few online and traditional platforms connected provide these and the typical use of distributed transactions leave even less opportunity for data and object locking.

Transactions

Invantive SQL has limited support for transactions. DML is forwarded to a platform and depending on the platform an error can cause part of the work to be registered or everything to be rolled back. Within the SQL engine, multiple changes can be collected and forwarded to the platform at once. For instance, when creating an EDIFACT message you need to combine an invoice header with invoice lines into one EDIFACT message. Collection of multiple changes is done using the 'identified by' and 'attach to' syntax, optionally preceded by 'begin transaction'.

Format Masks

Operations such as to_char and to_date support a limited number of format masks:

• YYYY: 4-digit year.
• YYYYMM: 4-digit year, plus 2-digit number month within year.
• YYYYMMDD: 4-digit year, 2-digit month number within year, plus 2-digit day number within month.
• YYYYMMDDHH24MI: 4-digit year, 2-digit month number within year, 2-digit day number within month, 2-digit 24-hour clock hour number, plus 2-digit minutes number within hour.
• YYYYMMDDHH24MISS: 4-digit year, 2-digit month number within year, 2-digit day number within month, 2-digit 24-hour clock hour number, 2-digit minutes number within hour, plus 2-digit seconds number within minute.
• YYYY-MM-DD: 4-digit year, dash ('-'), 2-digit month number within year, dash ('-'), plus 2-digit day number within month.
• YYYY-MM-DD HH24:MI:SS: 4-digit year, dash ('-'), 2-digit month number within year, dash ('-'), plus 2-digit day number within month, 2-digit hour on 24 hour clock, colon (':'), 2-digit minutes within hour, colon (':'), 2-digit seconds within minutes.
• YYYY/MM/DD: 4-digit year, slash ('/'), 2-digit month number within year, slash ('/'), plus 2-digit day number within month.
• YYYY/MM/DD HH24:MI:SS: 4-digit year, slash ('/'), 2-digit month number within year, slash ('/'), plus 2-digit day number within month, 2-digit hour on 24 hour clock, colon (':'), 2-digit minutes within hour, colon (':'), 2-digit seconds within minutes.
• MMDDYY: 2-digit month number within year, 2-digit day number within month, plus 2-digit year.
• MMDDYYYY: 2-digit month number within year, 2-digit day number within month, plus 4-digit year.
• DDMMYYYY: 2-digit day number within month, 2-digit month number within year, 4-digit year.
• DD-MM-YY: 2-digit day number within month, dash ('-'), 2-digit month number within year, dash ('-'), 2-digit year.
• DD-MMM-YY: 2-digit day number within month, dash ('-'), short month name, dash ('-'), 2-digit year.
• DD/MM/YY: 2-digit day number within month, slash ('/'), 2-digit month number within year, slash ('/'), 2-digit year.
• DD/MMM/YY: 2-digit day number within month, slash ('/'), short month name, slash ('/'), 2-digit year.
• DD-MM-YYYY: 2-digit day number within month, dash ('-'), 2-digit month number within year, dash ('-'), 4-digit year.
• DD-MMM-YYYY: 2-digit day number within month, dash ('-'), short month name within year, dash ('-'), 4-digit year.
• DD/MM/YYYY: 2-digit day number within month, slash ('/'), 2-digit month number within year, slash ('/'), 4-digit year.
• DD/MMM/YYYY: 2-digit day number within month, slash ('/'), short month name within year, slash ('/'), 4-digit year.
• DD-MM-YYYY HH24:MI:SS: 2-digit day number within month, dash ('-'), 2-digit month number within year, dash ('-'), 4-digit year, space (' '), 2-digit hour on 24 hour clock, colon (':'), 2-digit minutes within hour, colon (':'), 2-digit seconds within minutes.
• DD/MM/YYYY HH24:MI:SS: 2-digit day number within month, slash ('/'), 2-digit month number within year, slash ('/'), 4-digit year, space (' '), 2-digit hour on 24 hour clock, colon (':'), 2-digit minutes within hour, colon (':'), 2-digit seconds within minutes.
• DD/MMM/YYYY HH24:MI:SS: 2-digit day number within month, slash ('/'), short month name within year, slash ('/'), 4-digit year, space (' '), 2-digit hour on 24 hour clock, colon (':'), 2-digit minutes within hour, colon (':'), 2-digit seconds within minutes.
• YYYYIW: 4-digit year, plus ISO week number.
• YYYY-IW: 4-digit year, dash ('-'), plus ISO week number.
• IW: ISO week number.
• D: day of week according to ISO 8601.
• MMMM DD, YYYY HH24:MI TT: long month, 2-digit day number within month, comma (','), space (' '), 4-digit year number, space (' '), 2-digit hour on 24 hour clock, colon (':'), 2-digit minute within hour, space (' '), time zone.

sqlBatch ::= sqlOrPSqlStatement ( BATCHSEPARATOR sqlOrPSqlStatement )* BATCHSEPARATOR?

no references

sqlOrPSqlStatement:

sqlOrPSqlStatement
         ::= sqlStatement
           | pSqlStatement
           | pSqlCreateFunction
           | pSqlCreateProcedure
           | pSqlAlterFunction
           | pSqlAlterProcedure
           | pSqlDropFunction
           | pSqlDropProcedure

referenced by:

• sqlBatch

sqlStatement:

An Invantive SQL can retrieve data from many traditional and online platforms. Many platforms also support the use of DML (Data Manipulation Language) statements to change the data contained. On a few platforms you can execute DDL (Data Definition Language) statements to create new data structure or objects such as tables, procedures or sequences.

sqlStatement
         ::= selectStatement
           | insertStatement
           | updateStatement
           | deleteStatement
           | ddlStatement
           | setStatement
           | useStatement
           | transactionStatement
           | executeFileStatement
           | synchronizeStatement

referenced by:

• pSqlStatement
• sqlOrPSqlStatement

selectStatement:

A SQL select statement retrieves data from one or multiple data containers. A select statement can be composed of multiple data sets retrieved from many platforms, combined by set operators such as 'union'.

Often the performance of cloud platforms is less than traditional database platforms. With the 'limit' clause a limited number of rows can be retrieved quickly from a table or view after applying sorting as specified by the possibly present 'order by'. An alternative for a 'limit' clause is to use the 'top' clause.

A sequence of Invantive SQL statements, separated by the semi-colon separator character.

Each statement in the SQL batch will be executed consecutively. Execution will be stopped when an error occurs during execution of a statement.

selectStatement
         ::= uniqueSelectStatement setOperatorSelectStatement* orderBy? limitClause?

referenced by:

• arithmeticExpression
• createTableStatement
• embeddedSelect
• inSelectStatement
• insertStatement
• pSqlForRecordLoopStatement
• sqlStatement
• useStatement

inSelectStatement:

A SQL select statement retrieves data from one or multiple data containers. This variant makes this data available to a containing SQL select statement. This feature is also known as an 'inline view'.

inSelectStatement
         ::= selectStatement

referenced by:

• predicateExpression

setOperatorSelectStatement:

SQL is based upon a solid mathematical foundation named 'set theory' with some exceptions. The set operators of Invantive SQL enable you to combine sets of data sets such as merging two sets of data. Please note that SQL actually uses 'bags', which opposed to 'sets', allow duplicates. To change bags of data into sets, either use 'distinct' or the 'union' set operator without 'all'. In general, the extensive use of 'distinct' signals bad database design.

The 'union' set operator returns the union of the data on the left and right side of the union while removing duplicate rows. The 'union all' set operator returns the union of the data on the left and right side of the union without removing duplicate rows. The 'minus' set operator returns all rows from the left side which do not occur in the right side. The 'intersect' set operator returns all rows that occur both in the left and right side.

The 'union' set operator has an extension to facilitate sieving overlapping data sets of decreasing quality using 'distinct on'. The 'union distinct on' set operator returns the union of the data sets listed, but only the first match on the column list is returned. The first match is defined as a fallthrough from left to right. In general, the preferred source of a set of data is listed first, followed by one or multiple 'union distinct on' set operators, each with a data set of less preference.

setOperatorSelectStatement
         ::= ( UNION ( ALL | DISTINCT ON columnList )? | MINUS_C | INTERSECT ) uniqueSelectStatement

referenced by:

• selectStatement

uniqueSelectStatement:

Retrieves a data set from one or more data containers.

uniqueSelectStatement
         ::= select executionHints? distinct? topClause? selectList ( INTO pSqlVariableList )? ( FROM dataSource joinStatements? whereClause? )? groupBy?

referenced by:

• selectStatement
• setOperatorSelectStatement

dataSource:

A data source can be a table, a table with parameters or a nested select (an 'inline view'). Also, a data source can be a binary or text string being interpreted as XML, CSV, JSON or binary Excel Open XML format.

dataSource
         ::= ( tableOrFunctionSpec | embeddedSelect | xmlTableSpec | csvTableSpec | jsonTableSpec | excelTableSpec | stringSplitSpec ) aliased?

referenced by:

• joinStatement
• uniqueSelectStatement

select:

select   ::= SELECT

referenced by:

• uniqueSelectStatement

executionHints:

Execution hints allow you to control individually the execution of SQL statements. Whenever possible, the hints will be used. In contrary to other platforms, Invantive SQL requires a hint to be valid according to the grammar when specified. This reduces the engineering risk that hints become invalid by accident.

executionHints
         ::= EXECUTION_HINT_START ( joinSet | noJoinSet | ods | resultSetName | lowCost | httpDiskCache | httpMemoryCache )* EXECUTION_HINT_END

referenced by:

• uniqueSelectStatement

httpDiskCache:

The http_disk_cache-hint specifies whether messages may be cached on disk when the provider uses HTTP to exchange data with the backing platform. This typically holds only for cloud-based platforms such as Exact Online, Teamleader or Salesforce. The default setting is false. The first parameter is a boolean whether data may be taken from the disk cache, the second parameter is a boolean whether data retrieved must be stored also in the disk cache and the third parameter is an integer that specifies the number of seconds before a disk cache hit found is to considered stale.

The use of the http_disk-cache-hint is recommended for data which is known to change seldom such as seeded or reference data. The contents of the disk cache are persistent across Invantive SQL sessions.

The disk cache is located in the Cache folder of the Invantive configuration folder.

httpDiskCache
         ::= HTTP_DISK_CACHE ( PARENTHESIS_OPEN booleanConstant ( COMMA booleanConstant ( COMMA intervalConstant )? )? PARENTHESIS_CLOSE )?

referenced by:

• executionHints

httpMemoryCache:

The http_memory_cache-hint specifies whether messages may be cached in memory when the provider uses HTTP to exchange data with the backing platform. This typically holds only for cloud-based platforms such as Exact Online, Teamleader or Salesforce. The default setting is false. The first parameter is a boolean whether data may be taken from the memory cache, the second parameter is a boolean whether data retrieved must be stored also in the memory cache and the third parameter is an integer that specifies the number of seconds before a memory cache hit found is to considered stale.

The use of the http_memory-cache-hint is recommended for data which is known to change seldom such as seeded or reference data. The contents in the memory cache are forgotten across Invantive SQL sessions.

The memory cache is located in the Cache folder of the Invantive configuration folder.

httpMemoryCache
         ::= HTTP_MEMORY_CACHE ( PARENTHESIS_OPEN booleanConstant ( COMMA booleanConstant ( COMMA intervalConstant )? )? PARENTHESIS_CLOSE )?

referenced by:

• executionHints

ods:

The ods-hint controls the use of the Invantive Data Cache stored in a relational database. The Invantive Data Cache is also the basis of the Operational Data Store managed by Invantive Data Replicator and the data warehouses managed by Invantive Data Vault. The ods-hint specifies the maximum age data from the data cache eligible for use.

The boolean specifies whether the Data Cache may be used to answer a query. Set it to false to disable use of Data Cache for the duration of the query. Keep it on the default true to use Data Cache.

The interval specifies the period of time during which cached results are considered sufficiently fresh for use, such as '30 minutes'.

When no interval is present, the actual platform is consulted. The default with Invantive Data Cache enabled is to always use the data cache contents when not stale according to the metadata of the data cache. In general, that defaults to a maximum age of 7 days.

ods      ::= ODS ( PARENTHESIS_OPEN booleanConstant ( COMMA intervalConstant )? PARENTHESIS_CLOSE )?

referenced by:

• executionHints

resultSetName:

resultSetName
         ::= RESULT_SET_NAME ( PARENTHESIS_OPEN stringConstant PARENTHESIS_CLOSE )?

referenced by:

• executionHints

joinSet:

Control join approach between two data sources. A column-indexed lookup will be used instead of a full table scan when the number of rows on the left-hand side does not exceed the maximum number of rows specified in the hint. When not specified, a hash lookup will only be used when the number of rows on the left-side does not exceed 5.000.

The actual implementation of a hash lookup depends on the platform on which the data container runs. For instance with OData, a number of requests will be made using an in-construct with a limited number of in-values. With a relation database platform, a native SQL 'in' will be used.

The first identifier is the alias of the table on the right-hand side of the join. The second identifier is the name of the column used to join upon in the right-hand side. The numeric constant specifies upto what number of rows on the left-hand side of the join will allow the join set hint to be used. When the number of rows exceeds the numeric constant, a full table join is made.

The following example takes for instances 5.000 sales invoices from an Exact Online environment with 100.000 sales invoices. Each sales invoice has 4..10 lines. The join does not retrieve all sales invoices nor all invoice lines, but instead fetches the 5.000 sales invoices using the where-clause, and then retrieves the related invoice lines using a column-indexed lookup by invoiceid. Since Exact Online is an OData source, the approximately 30.000 invoice lines will be retrieves in 300 session I/Os each having an in-construct for 100 lines on invoiceid.

joinSet  ::= JOIN_SET PARENTHESIS_OPEN identifier ( COMMA identifier ( COMMA numericConstant )? )? PARENTHESIS_CLOSE

referenced by:

• executionHints

noJoinSet:

The no_join_set hint disables the use of hash-joins. It can be enabled using the join_set hint.

noJoinSet
         ::= NO_JOIN_SET PARENTHESIS_OPEN identifier ( COMMA identifier )? PARENTHESIS_CLOSE

referenced by:

• executionHints

lowCost:

The low_cost-hint specifies that the select with the hint must be considered a select with low execution costs. Low execution costs trigger early evaluation during parsing. By default, select statements using solely in memory storage, dummy and data dictionary are considered low cost and evaluated early. The evaluation of all others is delayed as long as possible.

The use of the low_cost-hint is recommended when the select is used with a 'in ( select ... )' syntax and the developer knows beforehand that it will evaluate fast to values and that the use of these values will allow the use of server-side filtering for the outer select.

lowCost  ::= LOW_COST

referenced by:

• executionHints

distinct:

Addition of the 'distinct' keyword to a SQL select statement de-duplicates the rows returned. Rows are considered duplicates when the values in all selected columns are identical, with two null-values considered equal.

distinct ::= DISTINCT

referenced by:

• aggregateFunction
• uniqueSelectStatement

topClause:

With the 'top' clause a limited number of rows can be retrieved quickly from a table or view after applying sorting as specified by the possibly present 'order by'.

topClause
         ::= TOP numericConstant

referenced by:

• uniqueSelectStatement

limitClause:

With the 'limit' clause a limited number of rows can be retrieved quickly from a table or view after applying sorting as specified by the possibly present 'order by'.

limitClause
         ::= LIMIT numericConstant

referenced by:

• selectStatement

embeddedSelect:

An embedded select, also known as an 'inline view', retrieves rows using the specified select statement. These rows are consumed by the outer select as were it the results of retrieving the rows from a table.

Invantive SQL does not allow grouping rows with expressions as columns. An embedded select is typically used to evaluate expressions to rows with solely constants. After applying the embedded select the group operators can be applied.

embeddedSelect
         ::= parenthesisOpen selectStatement parenthesisClose

referenced by:

• dataSource

tableSpec:

A table specification without parameters. The optional alias after the at-sign specifies a specific data source to be used, such as 'exactonlinerest..journals@eolbe' specifying the use of Exact Online Belgium when 'eolbe' is associated by the database definitions in settings.xml with Exact Online Belgium.

A number of special so-called 'service providers' are always present, such as 'datadictionary' for use by an alias.

tableSpec
         ::= fullTableIdentifier distributedAliasDirective?

referenced by:

• alterPersistentCacheConfigureWebhooksStatement
• alterPersistentCacheDropStatement
• alterPersistentCacheSetTableOptions
• alterPersistentCacheTableRefreshStatement
• applyToClause
• createTableStatement
• deleteStatement
• dropTableStatement
• insertStatement
• synchronizeStatement
• updateStatement

tableOrFunctionSpec:

A table specification requiring a comma-separated list of parameters to determine the rows to be retrieved.

Traditional SQL syntax did not provide for parameterized queries, matching set theory. Modern variants such as pipelined table functions allow a stored procedure or other imperative language-based approaches to generate rows based upon parameter values. Many data containers support queries that returns rows based upon parameter values. This holds especially for SOAP web services. Table specifications with parameters ease queries on such data containers.

The optional alias after the at-sign specifies a specific data source to be used, such as 'exactonlinerest..journals@eolbe' specifying the use of Exact Online Belgium when 'eolbe' is associated by the database definitions in settings.xml with Exact Online Belgium.

tableOrFunctionSpec
         ::= fullTableIdentifier tableFunctionSpec? distributedAliasDirective?

referenced by:

• dataSource

tableFunctionSpec:

A comma-separated list of parametres to determine the rows to be retrieved by a tableOrFunctionSpec.

tableFunctionSpec
         ::= parenthesisOpen ( namedExpressionList | expressionList )? parenthesisClose

referenced by:

• tableOrFunctionSpec

expressionList:

expressionList
         ::= expression ( COMMA expression )*

referenced by:

• tableFunctionSpec

namedExpressionList:

namedExpressionList
         ::= namedExpression ( COMMA namedExpression )*

referenced by:

• tableFunctionSpec

namedExpression:

namedExpression
         ::= identifier ASSOCIATION_OPERATOR expression

referenced by:

• namedExpressionList

distributedAliasDirective:

The distributed alias after the at-sign specifies a specific data source to be used, such as 'exactonlinerest..journals@eolbe' specifying the use of Exact Online Belgium when 'eolbe' is associated by the database definitions in settings.xml with Exact Online Belgium.

A number of special so-called 'service providers' are always present, such as 'datadictionary' for use by an alias.

distributedAliasDirective
         ::= AT dataContainerAlias

referenced by:

• partitionIdentifierWithAlias
• setIdentifier
• tableOrFunctionSpec
• tableSpec

dataContainerAlias:

When multiple data containers have been defined in settings.xml for a database, each one is assigned an alias. An alias typically takes the form of a limited number of characters. The presence of an alias allows Invantive SQL to precisely determine to what data container forward a request for data.

dataContainerAlias
         ::= identifier

referenced by:

• alterPersistentCacheRefreshStatement
• distributedAliasDirective

passingSourceOrPathExpression:

The passing option specifies the source of the contents to be interpreted. The contents can be specified as the outcome of an expression such as from a previous read_file() table function, a URL downloaded using httpget() or a string concatenation. The contents can also be specified as to be taken from a specific file identified by it's file name and path as an expression.

passingSourceOrPathExpression
         ::= PASSING FILE? expression

referenced by:

• csvTablePassing
• excelTablePassing
• jsonTablePassing
• xmlTablePassing

xmlTableSpec:

Data stored in XML format can be interpreted as a data source using the xmltable keyword.

The expression specifies a master XPath expression within the context of which the rows are evaluated using the column specifications.

The passing option specifies the source of the data in XML format. The source is often the outcome of a read_file() table function, a URL download using httpget() or a previous xmlformat() SQL function.

The columns are specified using their XPath relative to the master path.

xmlTableSpec
         ::= XMLTABLE parenthesisOpen ( expression | null )? ( xmlTablePassing | xmlTableLiteral ) xmlTableColumns parenthesisClose

referenced by:

• dataSource

xmlTablePassing:

xmlTablePassing
         ::= passingSourceOrPathExpression

referenced by:

• xmlTableSpec

xmlTableLiteral:

xmlTableLiteral
         ::= LITERAL expression

referenced by:

• xmlTableSpec

xmlTableColumns:

A list of XML table column specifications.

xmlTableColumns
         ::= COLUMNS xmlTableColumnSpec ( COMMA xmlTableColumnSpec )*

referenced by:

• xmlTableSpec

xmlTableColumnSpec:

The columns are specified using their XPath relative to the master path.

xmlTableColumnSpec
         ::= identifier dataType PATH stringConstant

referenced by:

• xmlTableColumns

jsonTableSpec:

Data stored in JSON format can be interpreted as a data source using the jsontable keyword.

The expression specifies a master JSON expression within the context of which the rows are evaluated using the column specifications.

The passing option specifies the source of the data in JSON format. The source is often the outcome of a read_file() table function or a URL download using httpget().

The columns are specified using their JSON path relative to the master path.

jsonTableSpec
         ::= JSONTABLE parenthesisOpen ( expression | null )? ( jsonTablePassing | jsonTableLiteral ) jsonTableColumns parenthesisClose

referenced by:

• dataSource

jsonTablePassing:

jsonTablePassing
         ::= passingSourceOrPathExpression

referenced by:

• jsonTableSpec

jsonTableLiteral:

jsonTableLiteral
         ::= LITERAL expression

referenced by:

• jsonTableSpec

jsonTableColumns:

A list of JSON table column specifications.

jsonTableColumns
         ::= COLUMNS jsonTableColumnSpec ( COMMA jsonTableColumnSpec )*

referenced by:

• jsonTableSpec

jsonTableColumnSpec:

The columns are specified using their JSON path relative to the master path.

jsonTableColumnSpec
         ::= identifier dataType PATH stringConstant

referenced by:

• jsonTableColumns

csvTableSpec:

Data stored in CSV format can be interpreted as a data source using the csvtable keyword.

The passing option specifies the source of the data in CSV format. The source is often the outcome of a read_file() table function or a URL download using httpget().

The interpretation process can be controlled on table level using the table options and the specification ends with the CSV columns being mapped to data source columns using their relative position within a row.

csvTableSpec
         ::= CSVTABLE parenthesisOpen ( csvTablePassing | csvTableLiteral ) csvTableOptions csvTableColumns parenthesisClose

referenced by:

• dataSource

csvTableOptions:

The interpretation process can be controlled on table level using the table options.

The row delimiter is a text that separates two CSV rows, such as "chr(13) || chr(10)" or simply a pipe character "'|'". The default is the operating system-specific variant of new line.

The column delimiter is a text that separates two CSV columns such as "';'". The default is comma.

Data in CSV will typically have one or more header CSV rows labeling the individual columns. The 'skip lines' statement excludes the first number of CSV rows from processing.

csvTableOptions
         ::= ( ROW DELIMITER expression )? ( COLUMN DELIMITER expression )? ( SKIP_ LINES expression )?

referenced by:

• csvTableSpec

csvTableLiteral:

csvTableLiteral
         ::= LITERAL expression

referenced by:

• csvTableSpec

csvTablePassing:

csvTablePassing
         ::= passingSourceOrPathExpression

referenced by:

• csvTableSpec

csvTableColumns:

A list of CSV table column specifications.

csvTableColumns
         ::= COLUMNS csvTableColumnSpec ( COMMA csvTableColumnSpec )*

referenced by:

• csvTableSpec

csvTableColumnSpec:

Each CSV column is mapped to a data source column using it's relative position within the CSV row. Position 1 represents the first CSV column.

csvTableColumnSpec
         ::= identifier dataType POSITION numericConstant

referenced by:

• csvTableColumns

excelTableSpec:

Excel file contents in Open XML, such as used with the file extensions xlsx and xlsm, can be interpreted as a data source using the exceltable keyword.

The rectangle specifies the rectangular area from which should be taken. Rows in Excel are interpreted as rows from the data source, whereas columns in Excel are interpreted as columns.

The passing option specifies the source of the (binary) contents in zipped Open XML format such as used with the file extensions xlsx and xlsm. The source is often the outcome of a read_file() table function or URL download using httpget().

The interpretation process can be controlled on table level using the table options and the specification ends with the Excel columns being mapped to data source columns using their relative position within the rectangular area.

excelTableSpec
         ::= EXCELTABLE parenthesisOpen excelDataRectangle excelTablePassing excelTableOptions excelTableColumns parenthesisClose

referenced by:

• dataSource

excelDataRectangle:

The rectangle specifies the rectangular area from which data should be taken. Rows in Excel are interpreted as rows from the data source, whereas columns in Excel are interpreted as columns. All cells within the rectangle are considered data; headings should be excluded from the rectangle specification.

A rectangle can be either:

• the contents of a complete worksheet, specified by an expression returning the worksheet name;
• a named range within a specific worksheet, specified by expressions for worksheet name and named range name;
• a cell range identified by an expression with it's dimensions;
• an Excel table identified by an expression with the table name;
• a named range identified by an expression with the named range name.

excelDataRectangle
         ::= ( WORKSHEET ( expression NAME )? | AREA | TABLE | NAME ) expression

referenced by:

• excelTableSpec

excelTablePassing:

excelTablePassing
         ::= passingSourceOrPathExpression

referenced by:

• excelTableSpec

excelTableOptions:

The interpretation process can be controlled on table level using the table options.

Empty rows will typically be found when consuming a rectangular area larger than the actual data, such a complete worksheet. The 'skip empty rows' statement eliminates all completely empty rows from the output.

excelTableOptions
         ::= ( SKIP_ EMPTY ROWS )? ( SKIP_ FIRST numericConstant ROWS )? ( SKIP_ LAST numericConstant ROWS )?

referenced by:

• excelTableSpec

excelTableColumns:

A list of Excel table column specifications.

excelTableColumns
         ::= COLUMNS excelTableColumnSpec ( COMMA excelTableColumnSpec )*

referenced by:

• excelTableSpec

excelTableColumnSpec:

Each Excel column is mapped to a data source column using it's relative position within the rectangular area. Position 1 represents the first Excel column falling within the Excel rectangular area.

excelTableColumnSpec
         ::= identifier dataType POSITION numericConstant

referenced by:

• excelTableColumns

stringSplitSpec:

stringSplitSpec
         ::= STRING_SPLIT parenthesisOpen expression COMMA expression parenthesisClose

referenced by:

• dataSource

dataTypeWithLength:

dataTypeWithLength
         ::= dataType ( parenthesisOpen numericConstant ( COMMA numericConstant )? parenthesisClose )?

referenced by:

• castExpression
• createTableArgument

dataType:

dataType ::= BFILE
           | BIGINT
           | BIGSERIAL
           | BIT
           | BLOB
           | BOOL
           | BOOLEAN
           | BPCHAR
           | BYTE
           | BYTEA
           | CHAR
           | CHARACTER
           | CLOB
           | DATE
           | DATETIME
           | DATETIMEOFFSET
           | DEC
           | DECIMAL
           | DOUBLE
           | FLOAT
           | FLOAT4
           | FLOAT8
           | GUID
           | IMAGE
           | INT
           | INT16
           | INT2
           | INT32
           | INT4
           | INT64
           | INT8
           | INTEGER
           | INTERVAL
           | LONGBLOB
           | LONGTEXT
           | MEDIUMBLOB
           | MEDIUMINT
           | MEDIUMTEXT
           | MONEY
           | NAME
           | NCHAR
           | NUMBER
           | NUMERIC
           | NVARCHAR
           | OID
           | PLS_INTEGER
           | RAW
           | REAL
           | SERIAL
           | SMALLDATETIME
           | SMALLINT
           | SMALLMONEY
           | SMALLSERIAL
           | TEXT
           | TIME
           | TIMESTAMP
           | TIMESTAMPTZ
           | TIMETZ
           | TINYBLOB
           | TINYINT
           | TINYTEXT
           | UINT16
           | UINT32
           | UINT64
           | UNIQUEIDENTIFIER
           | UUID
           | VARBINARY
           | VARCHAR
           | VARCHAR2
           | XML
           | XMLTYPE
           | YEAR

referenced by:

• csvTableColumnSpec
• dataTypeWithLength
• excelTableColumnSpec
• jsonTableColumnSpec
• pSqlArgument
• pSqlFunctionSpec
• pSqlItemDeclaration
• xmlTableColumnSpec

groupBy:

Grouping of multiple rows into groups is specified by the groupBy. A group will be introduced for each distinct combination of column values for the columns listed. The values of grouped columns can be used in the select clause. Columns not being grouped upon can only be used within the context of a group function listed as 'aggregateFunction'.

groupBy  ::= GROUP BY columnList

referenced by:

• uniqueSelectStatement

orderBy:

Sort the rows returned as specified by the list of columns. Values are either sorted ascending (the default) or descending.

orderBy  ::= ORDER BY sortedColumnList

referenced by:

• aggregateFunction
• selectStatement

sortDirection:

A sort direction can be either 'asc' for 'ascending' (the default) or 'desc' for 'descending'.

sortDirection
         ::= asc
           | desc

referenced by:

• sortedColumn

columnList:

A comma-separated list of columns.

columnList
         ::= column ( COMMA column )*

referenced by:

• groupBy
• identifiedByMultipleClause
• insertFieldList
• setOperatorSelectStatement

sortedColumnList:

sortedColumnList
         ::= sortedColumn ( COMMA sortedColumn )*

referenced by:

• orderBy
• resolveByClause

sortedColumn:

sortedColumn
         ::= column sortDirection?

referenced by:

• sortedColumnList

column:

A column is identified by an identifier, possibly prefixed by the name of the table or the alias of the table from which the column is to be taken.

column   ::= identifier ( DOT identifier )?

referenced by:

• columnList
• sortedColumn
• updateValue

whereClause:

The where-clause restricts the number of rows in a result set by applying one or more boolean condiditions which rows must satisfy.

whereClause
         ::= WHERE booleanExpression

referenced by:

• deleteStatement
• uniqueSelectStatement
• updateStatement

joinStatements:

A list of join statement.

joinStatements
         ::= joinStatement+

referenced by:

• uniqueSelectStatement

joinStatement:

A join statement combines two result sets. Only combinations of rows taken from both result sets are returned when they meet the join conditions.

joinStatement
         ::= joinCategory join dataSource joinConditions?

referenced by:

• joinStatements

joinCategory:

The join category specifies what combinations of rows are considered. The following variants can be used:

• inner join, as indicated by 'join' or 'inner join': an inner join returns all combinations of rows from both result sets that meet the join conditions.
• left outer, as indicated by 'left outer join': a left outer join returns the same rows as an inner join, extended by one row for each row in the left result set having no matching rows in the right result set. Each column that originates from the right result set is assigned a null value.
• right outer, as indicated by 'right outer join': a right outer join returns the same rows as an inner join, extended by one row for each row in the right result set having no matching rows in the left result set. Each column that originates from the left result set is assigned a null value.
• full outer, as indicated by 'full outer join': a full outer join returns the same rows as an inner join, extended by one row for each row in the right result set having no matching rows in the left result set. Each column that originates from the left result set is assigned a null value. The results are also extended by one row for each row in the left result set having no matching rows in the right result set. Each column that originates from the right result set is assigned a null value.
• cross join, as indicated by 'cross join': a cross join returns a Cartesian product of the rows from both result sets. A 'Cartesian product' is a term from set theory, which indicates that all combinations are returned.

joinCategory
         ::= ( inner | joinSubCategory outer? | cross )?

referenced by:

• joinStatement

joinSubCategory:

The join sub-category refines the join category. Please see 'joinCategory' for an explanation.

joinSubCategory
         ::= left
           | right
           | full

referenced by:

• joinCategory

join:

join     ::= JOIN

referenced by:

• joinStatement

inner:

inner    ::= INNER

referenced by:

• joinCategory

outer:

outer    ::= OUTER

referenced by:

• joinCategory

left:

left     ::= LEFT

referenced by:

• functionExpression
• joinSubCategory

right:

Extracts a substring from a value with the given length from the right side.
Parameters:

• Input: Text to extract substring from.
• Length: Maximum length of the substring.

right    ::= RIGHT

referenced by:

• functionExpression
• joinSubCategory

full:

full     ::= FULL

referenced by:

• joinSubCategory

cross:

cross    ::= CROSS

referenced by:

• joinCategory

sum:

Group function to sum together individual numerical values. Occurrences of null are considered 0, unless there are only null values. In that case the outcome is null.

sum      ::= SUM

referenced by:

• aggregateFunction

product:

Group function to multiply together individual numerical values. Multiplying large values can quickly exceed the range of the resulting Decimal data type. The product group function is typically used in financial and probability calculations with values near 1.

product  ::= PRODUCT

referenced by:

• aggregateFunction

min:

Group function to find the minimum value from a group of numerical values.

min      ::= MIN

referenced by:

• aggregateFunction

max:

Group function to find the maximum value from a group of numerical values.

max      ::= MAX

referenced by:

• aggregateFunction

avg:

Group function to find the average value from a group of numerical values.

avg      ::= AVG

referenced by:

• aggregateFunction

first:

Group function to the first non-null value in an ordered result set.

first    ::= FIRST

referenced by:

• aggregateFunction

last:

Group function to the last non-null value in an ordered result set.

last     ::= LAST

referenced by:

• aggregateFunction

stddev:

Group function to find the standard deviation from a group of numerical values.

stddev   ::= STDDEV

referenced by:

• aggregateFunction

count:

Group function to find the number of values from a group of values.

count    ::= COUNT

referenced by:

• aggregateFunction

listagg:

Group function which concatenates all individual values, separated by the separator when provided and comma plus space otherwise.

listagg  ::= LISTAGG

referenced by:

• aggregateFunction

asc:

asc      ::= ASC

referenced by:

• sortDirection

desc:

desc     ::= DESC

referenced by:

• sortDirection

joinConditions:

joinConditions
         ::= ON booleanExpression

referenced by:

• joinStatement

selectList:

selectList
         ::= selectPart ( COMMA selectPart )*

referenced by:

• uniqueSelectStatement

selectPart:

selectPart
         ::= part aliased? labeled?

referenced by:

• selectList

aliased:

aliased  ::= AS? alias

referenced by:

• dataSource
• selectPart

labeled:

labeled  ::= LABEL stringConstant

referenced by:

• selectPart

part:

part     ::= expression
           | aggregateFunction
           | allColumnsSpec

referenced by:

• aggregateFunction
• selectPart

aggregateFunction:

aggregateFunction
         ::= ( ( ( sum | product | avg | stddev ) parenthesisOpen distinct? | ( min | max | first | last ) parenthesisOpen ) arithmeticExpression | count parenthesisOpen distinct? part | zip parenthesisOpen arithmeticExpressionList | listagg parenthesisOpen distinct? arithmeticExpressionList ( parenthesisClose WITHIN GROUP parenthesisOpen orderBy )? ) parenthesisClose

referenced by:

• part

allColumnsSpec:

allColumnsSpec
         ::= allColumnsSpecId allColumnsSpecColumnNamePrefix? allColumnsSpecColumnNamePostfix? allColumnsSpecLabelPrefix? allColumnsSpecLabelPostfix?

referenced by:

• part

allColumnsSpecId:

allColumnsSpecId
         ::= ( alias DOT )? ASTERIX

referenced by:

• allColumnsSpec

allColumnsSpecColumnNamePrefix:

allColumnsSpecColumnNamePrefix
         ::= PREFIX WITH stringConstant

referenced by:

• allColumnsSpec

allColumnsSpecColumnNamePostfix:

allColumnsSpecColumnNamePostfix
         ::= POSTFIX WITH stringConstant

referenced by:

• allColumnsSpec

allColumnsSpecLabelPrefix:

allColumnsSpecLabelPrefix
         ::= LABEL PREFIX WITH stringConstant

referenced by:

• allColumnsSpec

allColumnsSpecLabelPostfix:

allColumnsSpecLabelPostfix
         ::= LABEL POSTFIX WITH stringConstant

referenced by:

• allColumnsSpec

ddlStatement:

All available Data Definition Language statements.

ddlStatement
         ::= createTableStatement
           | dropTableStatement
           | alterPersistentCacheStatement
           | alterDataDictionaryStatement
           | alterSessionStatement

referenced by:

• sqlStatement

alterPersistentCacheStatement:

Besides an in-memory cache valid during the duration of a session, Invantive SQL offers an integrated cache storing data persistently using an on-premise or cloud relation database such as SQL Server or PostgreSQL. When configured, Invantive SQL first tries to find sufficiently fresh data in the cache. This reduces the number of data loads from slow data containers such as some cloud platforms. In general, the performance increase when the rows can be fully retrieved from a cache is between a factor 25 and 2.500.

Invantive SQL itself manages the table structure and table contents in the relation database used as a data cache. On initial use just provide an empty database. Invantive SQL installs a repository consisting of a few tables. The repository tables have names starting with 'dc_'.

For each table partition version, a so-called facts table is created. A facts table contains a full copy of the rows retrieved from the data container. Facts tables have names starting with 'dcd_', followed by a unique hash signaling the table partition version. When necessary, additional database objects are maintained such as indexes to improve performance. As with facts table names, all column names are also hashed based upon an algorithm including the original column name. These facts tables are not intended for direct use using native SQL.

Each facts table has a unique state from the following state, with Ready state signaling the now current version:

• Initializing ('I'): the facts table will be created.
• View creation ('V'): logical views will be created.
• Prepared ('P'): the facts table has been created, but contains yet no rows.
• Seeding ('S'): the facts table is being seeded with the contents of the previously current version.
• Loading ('L'): loading new facts from data container using water shed or another algorithm.
• Ready ('R'): the facts table is available and the current one to be used.
• Obsoleted ('O'): the facts table still exists, but the data has passed it's conservation period. Often a newer version is now current.
• Dropped ('D'): the facts table now longer exist, but the metadata is still present in the repository tables.

The persistent cache in the database can be used with native SQL when extended by Invantive Data Replicator. Invantive Data Replicator can create and maintain a database view (a so-called 'partition view') for the now current version of table partition. Similarly, it can create an 'overall view', showing the rows across all partitions of the now current versions per partition.

The overall views are typically used for consolidation purposes, bringing together data across multiple companies or persons.

alterPersistentCacheStatement
         ::= alterPersistentCacheSetStatement
           | alterPersistentCacheDownloadStatement
           | alterPersistentCachePurgeStatement
           | alterPersistentCacheRefreshStatement
           | alterPersistentCacheLoadStatement
           | alterPersistentCacheTableRefreshStatement
           | alterPersistentCachePartitionRefreshStatement
           | alterPersistentCacheDropStatement
           | alterPersistentCacheConfigureWebhooksStatement

referenced by:

• ddlStatement

alterPersistentCachePurgeStatement:

alterPersistentCachePurgeStatement
         ::= ALTER PERSISTENT CACHE PURGE ( UNKNOWN | OBSOLETE | READY | DROPPABLE | ALL ) TABLE PARTITION VERSIONS ( DATACONTAINER stringConstant )?

referenced by:

• alterPersistentCacheStatement

alterPersistentCacheDownloadStatement:

alterPersistentCacheDownloadStatement
         ::= ALTER PERSISTENT CACHE DOWNLOAD FEED ( LICENSE CONTRACT CODE stringConstant )? ( TOKEN stringConstant )? ( DATACONTAINER stringConstant )? ( PARTITION partitionSimpleIdentifier )? ( LIMIT numericConstant )? ( NO DELETE )?

referenced by:

• alterPersistentCacheStatement

alterPersistentCacheConfigureWebhooksStatement:

Trickle loading is an advanced strategy to efficiently and fast update the replicate data. It requires all changes (insert, update and delete) on the replicated data to be registered as event messages, possibly with a delay.

The registration of changes can be activated on selected platforms using webhooks. Configuration of the webhooks can be done using this statement. When not specified, the license contract code of the current subscription will be used.

alterPersistentCacheConfigureWebhooksStatement
         ::= ALTER PERSISTENT CACHE ( ENABLE | DISABLE ) WEBHOOKS ( LICENSE CONTRACT CODE stringConstant )? ( TABLE tableSpec )? ( PARTITION partitionSimpleIdentifier )? ( DATACONTAINER stringConstant )?

referenced by:

• alterPersistentCacheStatement

alterPersistentCacheRefreshStatement:

This statement triggers the refresh of replicated data. A refresh of the replicated data can also be triggered by executing a SQL statement specifying the use of replicated data of a specific age.

In default mode (without 'force'), a refresh is only executed on the specified data when the age of the replicated data exceeds the configured maximum age. With a forced refresh, the replicated data is always replaced by a recent version of the source data.

The maximum number of parallel processes to replicate the data can be configured to increase throughput and decrease runtime of the replication process.

By default the approach as configured on each table partition is used to update the replica. However, a deviating approach can be specified. This is typically done after switching a table partition to trickle loading to run a one-time replication process with the copy approach, effectively ensuring that no changes have gone unnoticed.

alterPersistentCacheRefreshStatement
         ::= ALTER PERSISTENT CACHE FORCE? REFRESH ( DATACONTAINER dataContainerAlias? )? ( PARALLEL numericConstant )? ( APPROACH ( COPY | TRICKLE | SAMPLE | DEFAULT ) )?

referenced by:

• alterPersistentCacheStatement

alterPersistentCacheLoadStatement:

alterPersistentCacheLoadStatement
         ::= ALTER PERSISTENT CACHE LOAD

referenced by:

• alterPersistentCacheStatement

alterPersistentCacheTableRefreshStatement:

Refresh all data of a specificied table. The options are explained at alterPersistentCacheRefreshStatement.

alterPersistentCacheTableRefreshStatement
         ::= ALTER PERSISTENT CACHE TABLE tableSpec FORCE? REFRESH ( PARTITION partitionIdentifier )? ( PARALLEL numericConstant )? ( APPROACH ( COPY | TRICKLE | SAMPLE | DEFAULT ) )?

referenced by:

• alterPersistentCacheStatement

alterPersistentCachePartitionRefreshStatement:

Refresh all data of a specificied partition. The options are explained at alterPersistentCacheRefreshStatement.

alterPersistentCachePartitionRefreshStatement
         ::= ALTER PERSISTENT CACHE PARTITION partitionIdentifier FORCE? REFRESH ( PARALLEL numericConstant )? ( APPROACH ( COPY | TRICKLE | SAMPLE | DEFAULT ) )?

referenced by:

• alterPersistentCacheStatement

alterPersistentCacheDropStatement:

alterPersistentCacheDropStatement
         ::= ALTER PERSISTENT CACHE DROP ( TABLE tableSpec ( PARTITION partitionIdentifier )? | PARTITION partitionIdentifier | DATACONTAINER stringConstant )

referenced by:

• alterPersistentCacheStatement

alterPersistentCacheSetStatement:

alterPersistentCacheSetStatement
         ::= ALTER PERSISTENT CACHE SET ( ( FRESH | RETENTION FORWARDED INCOMING MESSAGES | METADATA? RECYCLEBIN | DATA MODEL VERSION ) numericConstant | TOKEN stringConstant | LOGICAL ( OVERALL | PARTITION ) VIEW ( NAME ( PREFIX | POSTFIX ) stringConstant | MAINTAIN booleanConstant ) | ( LOAD MY MESSAGES | INDEX ( FACTS | HISTORY ) TABLES ) booleanConstant | AUTO UPGRADE ONCE | alterPersistentCacheSetBackingConnectionString | alterPersistentCacheSetTableOptions | alterPersistentCacheSetDataContainerOptions )

referenced by:

• alterPersistentCacheStatement

alterPersistentCacheSetBackingConnectionString:

alterPersistentCacheSetBackingConnectionString
         ::= BACKING ENCRYPTED CONNECTION STRING stringConstant

referenced by:

• alterPersistentCacheSetStatement

alterPersistentCacheSetDataContainerOptions:

alterPersistentCacheSetDataContainerOptions
         ::= DATACONTAINER stringConstant LOGICAL OVERALL VIEW NAME ( PREFIX | POSTFIX ) stringConstant

referenced by:

• alterPersistentCacheSetStatement

alterPersistentCacheSetTableOptions:

alterPersistentCacheSetTableOptions
         ::= TABLE tableSpec ( LOGICAL ( OVERALL VIEW ( MAINTAIN booleanConstant | NAME stringConstant ) | PARTITION VIEW ( MAINTAIN booleanConstant | NAME ( PREFIX | POSTFIX ) stringConstant ) ) | INDEX ( FACTS | HISTORY ) TABLE booleanConstant | STATE ( OBSOLETE | DROPPED ) | ( PARTITION partitionIdentifier )? APPROACH ( COPY | TRICKLE | SAMPLE ) ( LICENSE CONTRACT CODE stringConstant )? )

referenced by:

• alterPersistentCacheSetStatement

alterDataDictionaryStatement:

alterDataDictionaryStatement
         ::= alterDataDictionarySetStatement

referenced by:

• ddlStatement

alterSessionStatement:

alterSessionStatement
         ::= alterSessionSetStatement

referenced by:

• ddlStatement

alterSessionSetStatement:

Change properties of the current Invantive SQL session.

alterSessionSetStatement
         ::= ALTER SESSION SET alterSessionSetBillingId

referenced by:

• alterSessionStatement

alterDataDictionarySetStatement:

Associate a persistent store to back the data dictionary associated with the current Invantive SQL session. The persistent store will be used to store and retrieve object definitions such as PSQL procedures, SQL views and PSQL packages.

alterDataDictionarySetStatement
         ::= ALTER DATA DICTIONARY SET alterDataDictionarySetBackingConnectionString

referenced by:

• alterDataDictionaryStatement

alterDataDictionarySetBackingConnectionString:

alterDataDictionarySetBackingConnectionString
         ::= BACKING ENCRYPTED CONNECTION STRING stringConstant

referenced by:

• alterDataDictionarySetStatement

alterSessionSetBillingId:

Change the ID used for to differentiate billing within one agreement. Typically used for hosted, OEM and white label use of Invantive products to associate usage statistics on data downloaded, data uploaded, users, devices and partitions use with individual billing IDs.

alterSessionSetBillingId
         ::= BILLING ID stringConstant

referenced by:

• alterSessionSetStatement

createTableStatement:

Create a table on the specified platform, filled with data from the select statement. An error is raised when a table with the same name already exists. When 'or replace' is specified, a previously existing table with the same name is dropped before creating the new table.

A new table is assigned a technical primary key column. Also indexes are created by default where deemed useful.

createTableStatement
         ::= CREATE orReplace? TABLE tableSpec ( AS selectStatement | parenthesisOpen createTableArgument ( COMMA createTableArgument )* parenthesisClose )

referenced by:

• ddlStatement

createTableArgument:

createTableArgument
         ::= identifier dataTypeWithLength ( NOT? NULL )?

referenced by:

• createTableStatement

dropTableStatement:

Drop the specified table on the specified platform. An error is raised when no table exists by that name.

dropTableStatement
         ::= DROP TABLE tableSpec

referenced by:

• ddlStatement

orReplace:

orReplace
         ::= OR REPLACE

referenced by:

• createTableStatement

setStatement:

Replaces the value of a provider attribute by a new value.

setStatement
         ::= SET setIdentifier expression

referenced by:

• sqlStatement

setIdentifier:

setIdentifier
         ::= attributeIdentifier distributedAliasDirective?

referenced by:

• setStatement

transactionStatement:

transactionStatement
         ::= beginTransactionStatement
           | rollbackTransactionStatement
           | commitTransactionStatement

referenced by:

• sqlStatement

executeFileStatement:

Execute a file loaded from the operating system with Invantive SQL statements. The file may contain Invantive SQL and Procedural SQL. The use of Invantive Script is not allowed.

executeFileStatement
         ::= FILE_PATH

referenced by:

• sqlStatement

beginTransactionStatement:

A begin transaction statement initiates a transaction. Invantive SQL typically provides no transaction logic given the distributed nature and the limitations of the possible platforms. Some platforms enable collection of transaction data, which are to be handed over to the backing platform all together.

beginTransactionStatement
         ::= BEGIN TRANSACTION?

referenced by:

• transactionStatement

rollbackTransactionStatement:

Forgets all collected transaction data not yet handed over to the backing platform.

rollbackTransactionStatement
         ::= ROLLBACK TRANSACTION?

referenced by:

• transactionStatement

commitTransactionStatement:

Hand over all collected transaction to the backing platform for registration.

commitTransactionStatement
         ::= COMMIT TRANSACTION?

referenced by:

• transactionStatement

useStatement:

The use statement enables you to specify which partitions should be accessed by subsequent select, insert, update and delete statements. You can specify one or multiple partitions as a comma-separated list, possibly for a specific data container by appending an at-sign plus data container alias to the partition code. The value 'default' has a special meaning; it specifies to use the partition(s) originally selected when you logged on. The value 'all' also has a special meaning: it selects all partitions available.

For instance, to select partition '35' in the data container with alias 'eolnl' and partition '57345' in the data container with alias 'nmbrsnl', you can execute: 'use 35@eolnl, 57345@nmbrsnl'.

For complex scenarios, you can specify any valid Invantive SQL select statement which returns one or two columns. Each row from the query specifies one partition to select. The first column specifies the partition code, whereas the optional second column specifies a specific data container alias.

For instance, to select partition '35' in the data container with alias 'eolnl' and partition '57345' in the data container with alias 'nmbrsnl', you can execute: 'use select '35', 'eolnl' from dual@datadictionary union all select '57345', 'nmbrsnl' from dual@datadictionary'.

useStatement
         ::= USE ( partitionIdentifiersList | selectStatement )

referenced by:

• sqlStatement

partitionIdentifiersList:

partitionIdentifiersList
         ::= partitionIdentifierWithAlias ( COMMA partitionIdentifierWithAlias )*

referenced by:

• useStatement

partitionIdentifier:

A partition identifier uniquely identifies one or more partitions from the currently available data containers.

The special partition identifer 'default' stands for all partitions that were chosen as default partitions during setup of the database connection. The special partition identifier 'all' stands for all available partitions across all available database connections.

partitionIdentifier
         ::= parameterExpression
           | numericConstant
           | identifier
           | ALL
           | DEFAULT

referenced by:

• alterPersistentCacheDropStatement
• alterPersistentCachePartitionRefreshStatement
• alterPersistentCacheSetTableOptions
• alterPersistentCacheTableRefreshStatement
• partitionIdentifierWithAlias

partitionIdentifierWithAlias:

partitionIdentifierWithAlias
         ::= partitionIdentifier distributedAliasDirective?

referenced by:

• partitionIdentifiersList

partitionSimpleIdentifier:

partitionSimpleIdentifier
         ::= numericConstant
           | identifier

referenced by:

• alterPersistentCacheConfigureWebhooksStatement
• alterPersistentCacheDownloadStatement

insertStatement:

insertStatement
         ::= bulk? insert into tableSpec ( insertFieldList valuesExpression | insertFieldList? selectStatement ) identifiedByClause? attachToClause?

referenced by:

• sqlStatement

valuesExpression:

valuesExpression
         ::= values_ ( insertValuesBulk | insertValues )

referenced by:

• insertStatement

bulk:

bulk     ::= BULK

referenced by:

• insertStatement

into:

into     ::= INTO

referenced by:

• insertStatement

insert:

insert   ::= INSERT

referenced by:

• insertStatement

values_:

values_  ::= VALUES

referenced by:

• valuesExpression

insertFieldList:

insertFieldList
         ::= parenthesisOpen columnList parenthesisClose

referenced by:

• insertStatement

insertValuesBulk:

insertValuesBulk
         ::= parenthesisOpen insertValues ( COMMA insertValues )* parenthesisClose

referenced by:

• valuesExpression

insertValues:

insertValues
         ::= parenthesisOpen insertValuesList parenthesisClose

referenced by:

• insertValuesBulk
• valuesExpression

insertValuesList:

insertValuesList
         ::= arithmeticExpression ( COMMA arithmeticExpression )*

referenced by:

• insertValues

identifiedByClause:

identifiedByClause
         ::= IDENTIFIED BY arithmeticExpression

referenced by:

• insertStatement

identifiedByMultipleClause:

identifiedByMultipleClause
         ::= IDENTIFIED BY columnList

referenced by:

• synchronizeStatement

attachToClause:

attachToClause
         ::= ATTACH TO arithmeticExpression

referenced by:

• insertStatement

updateStatement:

updateStatement
         ::= UPDATE FROM? tableSpec SET updateValuesList whereClause?

referenced by:

• sqlStatement

updateValuesList:

updateValuesList
         ::= updateValue ( COMMA updateValue )*

referenced by:

• updateStatement

updateValue:

updateValue
         ::= column EQ arithmeticExpression

referenced by:

• updateValuesList

deleteStatement:

deleteStatement
         ::= delete FROM? tableSpec whereClause?

referenced by:

• sqlStatement

delete:

delete   ::= DELETE

referenced by:

• deleteStatement

synchronizeStatement:

The compare and synchronize statement provides one-directional and bi-directional analysis and alignment of data in two tables. It is an extended version of SQL statements like 'upsert' and 'merge' found in other SQL implementations.

• insert: a row exists in the source table and not in the target table;
• delete: a row exists not in the source table, but exists in the target table;
• update: the row exists in both tables, but the column contents are different.
• none: the row exists in both tables and the column contents are equal.

Rows in both tables are matched using the list of columns as specified by 'IDENTIFIED BY'. Identifying column null contents are considered a specific value for matching; when both the source and target table have a null value, the rows will be matched.

After analysis, the differences can be filtered to only contain the type of operations specified using 'WITH' and then either be:

• applied on the target table to make the tables equal, using bulk operations where supported.
• returned as a list of content differences;
• returned as Invantive SQL DML-statements to achieve synchronization.

After analysis, the differences can be applied on the target table.

In a bi-directional approach, as specified by using the keyword 'AND' between the two table identifiers, deletes will not be returned from the analysis phase and replaced by inserts on the table which does not have the other table's row. The determination of the target for an update is based upon the resolution preference as defined by the 'RESOLVE' clause. The 'RESOLVE' clause either defines to always apply updates to the left or right table as listed in their order using, respectively, 'PREFER LEFT' and 'PREFER RIGHT'. Otherwise, the combined ordinal value of the columns listed in the 'RESOLVE BY' clause will be evaluated and the highest-ranking value is considered to be leading.

synchronizeStatement
         ::= ( synchronize | COMPARE ) tableSpec ( FROM | TO | AND ) tableSpec ( WITH INSERT? OR? UPDATE? OR? DELETE? )? identifiedByMultipleClause synchronizeIgnoreClause? resolveByClause? applyToClause? ( RETURNING ( SQL | DIFFERENCES ) )?

referenced by:

• sqlStatement

synchronize:

synchronize
         ::= SYNCHRONIZE
           | SYNC

referenced by:

• synchronizeStatement

synchronizeIgnoreClause:

synchronizeIgnoreClause
         ::= IGNORE NULLS

referenced by:

• synchronizeStatement

resolveByClause:

resolveByClause
         ::= RESOLVE ( BY sortedColumnList | PREFER ( LEFT | RIGHT ) )

referenced by:

• synchronizeStatement

applyToClause:

applyToClause
         ::= APPLY TO tableSpec ( COMMA tableSpec )?

referenced by:

• synchronizeStatement

expression:

expression
         ::= booleanExpression
           | arithmeticExpression

referenced by:

• caseElseExpression
• caseWhenThenExpression
• castExpression
• csvTableLiteral
• csvTableOptions
• excelDataRectangle
• expressionList
• jsonTableLiteral
• jsonTableSpec
• namedExpression
• pSqlAssignmentStatement
• pSqlExecuteImmediateStatementNS
• pSqlExecuteNativeStatementNS
• pSqlForNumberLoopStatement
• pSqlItemDeclaration
• pSqlRaiseStatement
• pSqlReturnStatement
• pSqlWhileLoopStatement
• part
• passingSourceOrPathExpression
• setStatement
• stringSplitSpec
• xmlTableLiteral
• xmlTableSpec

booleanExpression:

booleanExpression
         ::= ( not | booleanExpression ( and | or ) ) booleanExpression
           | parenthesisOpen booleanExpression parenthesisClose
           | predicateExpression
           | true
           | false

referenced by:

• booleanExpression
• expression
• joinConditions
• pSqlContinueStatement
• pSqlElsIfExpression
• pSqlExitStatement
• pSqlIfStatement
• whereClause

caseExpression:

caseExpression
         ::= case caseWhenThenExpression+ caseElseExpression? end

referenced by:

• arithmeticExpression

caseWhenThenExpression:

caseWhenThenExpression
         ::= when expression then arithmeticExpression

referenced by:

• caseExpression

caseElseExpression:

caseElseExpression
         ::= else expression

referenced by:

• caseExpression