Search Results buffer_size

Overview

EPS is an Oracle E-Business Suite PL/SQL package that provides an integration bridge between the EBS database and an external Oracle Express (OLAP) server. Its principal business function is to submit ad hoc multidimensional queries to an Express server, retrieve the resulting data sets, and materialize those results as strongly typed PL/SQL collections that calling EBS code can iterate over. The package header exposes a small, focused API centered on query execution and error translation, while the package body supplies the lower-level plumbing for preparing statements on the remote server, fetching rows in buffered batches, and converting raw result buffers into structured objects.

The package carries the header identifier epsuserb.pls 115.2, dating to 2002, and is classified under ETRM as OTHER rather than as a public business API. It is nonetheless referenced by other packages in the EBS schema, indicating it is a supporting utility layer for Express-based analytics rather than an end-user-facing interface. The body is organized around two external entry points, GETERRORMSG and QUERY, with the remaining routines acting as internal helpers.

Key Procedures and Functions

• QUERY — The primary public function. It accepts an Express server name and up to ten query parameters, obtains a unique report identifier from the EPS_REPORT_ID sequence, prepares the query against the target server, and loops over the result set. It declares an internal buffer_size of 4000 and passes that value to XPFETCHN to control batch retrieval, accumulating rows until the fetch signals completion (status 1403 or 0 with no further rows). It returns a table of Express row objects.
• GETERRORMSG — Translates a numeric status code into human-readable text. It calls XRBGETMESSAGE with a 2000-byte message buffer; if no message is found, it returns a generic "Unknown error code or message file missing" string. QUERY uses this function to raise application errors with meaningful text.
• XPPREPARE — Prepares a query on the designated Express server for the given report identifier. A nonzero return status is treated as fatal by QUERY.
• XPFETCH — Retrieves result data from a prepared Express report, forming the underlying fetch primitive.
• XPFETCHN — The batch fetch routine, invoked with the report identifier, the buffer_size, an output buffer, and output row and column counts. This is the routine most closely associated with the user's buffer_size search term: the value of 4000 bytes determines how much result data is returned per call and therefore governs fetch granularity and memory use.
• XRBGETMESSAGE — Retrieves error message text from the Express message file into a supplied buffer.
• PARSEROW and PARSECOL — Internal parsing helpers that decompose the raw fetch buffer into individual rows and columns, populating the table of EPS_express_t objects that QUERY returns.

Tables Accessed

• DUAL — Used to select the next value from EPS_report_id.NEXTVAL, generating a unique identifier for each query invocation.
• EPS_REPORT_ID — The sequence backing report identifier generation; each QUERY call consumes one value.
• EPS_LIB — A supporting library table associated with the EPS Express integration, referenced through APPS synonyms.
• PLITBLM — The standard EBS PL/SQL index-by table messaging synonym, consistent with the package's use of message buffers and error text handling.

Usage Notes

EPS is invoked programmatically rather than through a standard concurrent program or form. Custom code calls EPS.QUERY with a valid Express server name and query string, then iterates the returned collection. Because a nonzero prepare status raises an application error immediately, callers should wrap invocations in exception handlers and surface GETERRORMSG output to the user. The fixed buffer_size of 4000 constrains both throughput and memory footprint; deployments with very wide result sets should account for the fact that this value is hard-coded in the body rather than parameterized. Given its 2002 vintage and OTHER classification, the package should be treated as a legacy integration component when planning upgrades.