E-QAS: Why does QAS_EXECUTEQRY_REST_GET Return Integration Gateway Error Instead of Result Set Too Large? (Doc ID 2758710.1)

Last updated on MAY 29, 2024

Applies to:

Goal

Background and Questions:
-----------------------------------
Implementing query web services and seeing different behavior than expected. Noticing that the Max Fetch Size parameter in the application server config file doesn't apply to the queries executed via query web services. For example, running a Query in Query Viewer gives the expected message stating that the results are beyond the max fetch size, and so only a portion of the results are displayed. However when the same query is executed via QAS_EXECUTEQRY_REST_GET it continues to load and appears to crash the PSAPPSRV process. So using QAS_EXECUTEQRY_REST_GET rest service to execute a Query that returns the "Result Set Too Large" message when running online, receiving the following error for the QAS_EXECUTEQRY_REST_GET service instead...

The expectation is to see either an error returned that states the same as what is seen online, or at the very least the web service call is terminated sooner if the max fetch size is reached.

Q1. Should QAS return the same message as the Query when run in PIA, and Is there a way to limit the amount of rows returned without crashing, from the application server side of things?
Q2. If PSQRYSRV services are configured should Queries submitted via QAS_EXECUTEQRY_REST_GET run via PSQRYSRV instead of PSAPPSRV?

Q3. There is also concern with only relying on the “maxrows” if it can be manipulated in the URL then there is the potential to crash the appserver service so looking for a way for the server to protect against that scenario. Is there a way to account for or protect against that scenario of URL manipulation by any user?
Q4. Do the typical Query profile restrictions (i.e. max rows) still work for Queries run via QAS?

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.