SELECT processing by the IP is indicated when IP EXECUTE is called with statement type set to DAM_SELECT or DAM_SELECT_FOR_UPDATE. Execution of a SELECT operation can be handled in two ways: all at once, or by processing a set number of rows at a time (cursor-based processing). If the execution is split, then IP EXECUTE is called once with DAM_SELECT or DAM_SELECT_FOR_UPDATE and then multiple times with DAM_FETCH to process more rows and send them to the client. The IP developer decides which type of SELECT processing to implement.
If the IP is called multiple times to process a SQL query that contains a join or that can be broken into individual subqueries, the IP can set up the OpenAccess SDK SQL engine to indicate the start and end of query processing. Doing this is useful when the IP can perform the required setup once and not have to set up and clean up for each subquery. This mode is enabled by setting the IP_SUPPORT_START_QUERY and the IP_SUPPORT_END_QUERY support options. Start of query processing is indicated to the IP through the EXECUTE function with the statement type set to DAM_START_QUERY. End of query processing is indicated to the IP through the EXECUTE function with the statement type DAM_END_QUERY. This is the optimal method for join processing because the OpenAccess SDK SQL engine first processes a query on one table, and then performs one query for each row in the first table on the other table.
Whether cursor-based processing is used or not, results that require more than the specified amount of memory are cached to temporary disk storage. This allows for any size queries to be processed without using up large amounts of memory. All post-processing and fetching then happens from the disk. Refer to OpenAccess SDK Administrator’s Guide for details on setting up disk cache.
