skip to main content
Configuring the OpenAccess SDK SQL Engine : OpenAccess SDK SQL Engine Configuration Parameters : SQL Engine Parameters
 

SQL Engine Parameters

The following table lists the service attributes that control the behavior of the OpenAccess SDK SQL Engine. They are displayed in the SQL Engine Parameters category in the OpenAccess SDK Management Console. See OpenAccess SDK Service Attributes for more information about the service attributes.
Table 13. SQL Engine Parameters
Service Attribute
Description
Specifies the number of table definitions to cache in memory when using binary schema.
Specifies whether to check limits on table name length, number of columns in a table, column name length, number of tables in a SELECT statement, and other limits.
Specifies the name of the file to use for customized error messages for the SQL engine. If the specified file is not found, then the built-in error messages are used. The file name is assumed to be in the ServiceIPPath folder.
Specifies the amount to increase the disk cache files by when the space in the current disk cache file is exhausted. The default is 5 MB.
Specifies the initial size of the disk cache file in megabytes (MB). Estimate this size to allow most results to be saved without having to expand the disk cache file too many times. The default is 10 MB.
Specifies the maximum allowable size of the disk cache files (in megabytes). The default is 50 MB.
Describes the maximum amount of memory (in KB) to use for processing a query. If the result set size exceeds this value, the OpenAccess SQL engine starts caching records to disk. See Configuring Disk Cache for more details.
Describes the location where the disk cache files will be created. This directory must have appropriate privileges.
Specifies the string to use for prefixing error messages returned from the OpenAccess SDK SQL engine. Set the value to an empty string to remove the default message prefix.
Specifies the SQL plan logging level for the OpenAccess SDK SQL engine. When not set, SQL plan logging is disabled.
Allows finer control over the SQL engine tracing. Using ServiceSQLEngineVerboseLogLevel is not recommended unless specifically you are instructed by technical support to use this attribute.
Specifies the number of rows the OpenAccess SDK SQL Engine processes at a time. Setting this attribute to a very large number uses large amounts of memory.
Specifies whether to hide the Qualifier and Owner information that is returned as part of schema queries.
Specifies the number of rows of inner table data that are retrieved in one query during Block Join Processing. The query on the inner table will be passed up to this number of conditions.
Controls whether the join order is based on the order of the tables in the query or on the standard join algorithm.
Specifies whether to use the search conditions to determine the join order.
Controls whether the OpenAccess SDK SQL engine allows the use of locale specific decimal point separator in SQL queries. This only applies to literal in the query and not the parameter values.
Specifies the maximum size (in bytes) of the query that the OpenAccess SDK SQL engine will handle. An error is reported for queries that are larger than this limit. See also ServiceSQLTranslatedQueryMaxSize.
Specifies the memory page size (in rows) for the row nodes in the OpenAccess SDK SQL engine. See Configuring Disk Cache for more information.
Specifies the number of column value nodes allocated as one large memory block. See Configuring Disk Cache for more information.
Indicates whether static schema can be updated.
Controls how a sub-query is handled.
Specifies the buffer size to allocate for a translated query. The OpenAccess SDK SQL engine uses the value of ServiceSQLQueryMaxSize if the ServiceSQLTranslatedQueryMaxSize is smaller. An error is returned if the buffer is not large enough to handle a query submitted for execution.
Controls how a view is executed. A view can be executed by rewriting the query to combine the query defining the view and the query specified by the user. This results in the most efficient processing of queries on views. The alternative is to process the view as a sub-query and then perform the user-specified query on the results of the sub-query.