Note Check the solidDB Release Notes for any limitations that are associated with using a grid in the current release.
When using a solidDB grid with partitioned tables, you should be aware of the following SQL limitations.
Statement execution
Generally, all SELECT statements work with a grid the same as with a standalone solidDB database. Due to the distributed nature of a grid, the performance of complex queries must be assessed carefully. Typically, lookup queries that access a single row of data are expected to perform very well when run against a grid.
By default, INSERT, UPDATE, and DELETE statements that affect more than one row in the database are likely to fail unless all affected rows share the same partitioning key value (and are therefore stored on the same grid node).
It is possible to execute range-based UPDATE and DELETE statements by using the SET GRID WRITE DISTRIBUTED statement (see SET GRID WRITE) but, due to heavy lock escalation, this is only appropriate if there is no concurrent write load to the related table.
Triggers
Triggers execute in a grid the same way as in a standalone solidDB database but they are practical for only the following tasks:
▪ validating or modifying the contents of the current row (and forcing the operation to fail if necessary),
▪ executing SELECT, INSERT, or UPDATE operations on rows that share the same partitioning key as the current row.
Posting events inside the trigger code is not recommended, because applications that use grid connections cannot capture events.
Stored procedures
Although you can create and execute stored procedures in a grid environment, this is not recommended. The SQL statements in a procedure can access only data on the current grid node. If the application uses a grid connection, you cannot control the node on which the stored procedure is executed.