Commented by: @dyemanov

The error message surely deserves a better wording. As for the error itself, this issue is more complicated than it looks at the first glance. Personally, I'd expect it to execute without errors if used as a result set (prepare/fetch) but throw an error is executed as the statement (execute immediate). However, I doubt this is technically doable.

Commented by: Maxim Kuzmin (cybermax)

We have reports, queries that run through the EXECUTE BLOCK, where the output parameters are set as domain. And if some report returns an empty set, then this error occurs. Use TYPE OF or type the domain breaks the uniformity, convenience and check output parameters.

Commented by: @asfernandes

Dmitry, is it well known and documented that EXECUTE BLOCK can work different (like select * from SP / execute procedure SP) depending on the API function used?

I never paid attention to this. I always executed it in ISQL and for me the standard behavior has to need to issue a SUSPEND.

Commented by: @dyemanov

Nope. EXECUTE BLOCK with output params is described as select and hence usually executed via execute/fetch, thus needing SUSPEND. But, similar to any other [singleton] SELECT, nobody prevents you from executing it via execute_immediate. I suppose the caller might expect NULLs to be returned for the no-rows case. Our API wierdness, sigh (someone would call this flexibility).