Dmitry, Alex,
> 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).
This is what I'm seeing in 3.0, but not in 2.5, and I think the bug is
in 3.0.
And if I'm right, main reason of this bug can be fixed.
In 3.0, these lines (dsql.cpp - in two places) does not consider an
EXECUTE BLOCK executed via execute_immediate as singleton:
const bool singleton =
((statement->getType() ==
DsqlCompiledStatement::TYPE_SELECT) && out_msg);
In 2.5 it is:
const bool singleton = (reqTypeWithCursor(request->req_type) &&
out_msg_length != 0);
and reqTypeWithCursor considers REQ_SELECT_BLOCK
Then in 2.5, it enters here and throws an error:
else if (status == isc_req_sync && counter == 1)
status_exception::raise(Arg::Gds(isc_stream_eof));
So while 3.0 matches Dmitry's expectation, it changed the behavior of 2.5.
My tests of 2.5 is with the 3.0 API.
I've put the test here:
https://github.com/asfernandes/fbstuff/commit/72350d5a3d89f79ad7616522be81db9090668df4
Please see how the check need to be different for 3.0 to make the test
succeed.
Adriano
-------- Original Message --------
Subject: [FB-Tracker] Commented: (CORE-4184) Executing empty EXECUTE
BLOCK with NotNull output parameter raised error
Date: Tue, 20 Aug 2013 16:14:14 +0000 (GMT+00:00)
From: Dmitry Yemanov (JIRA) <[email protected]>
To: [email protected]
[
http://tracker.firebirdsql.org/browse/CORE-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27032#action_27032
]
Dmitry Yemanov commented on CORE-4184:
--------------------------------------
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).
> Executing empty EXECUTE BLOCK with NotNull output parameter raised error
> ------------------------------------------------------------------------
>
> Key: CORE-4184
> URL: http://tracker.firebirdsql.org/browse/CORE-4184
> Project: Firebird Core
> Issue Type: Bug
> Affects Versions: 2.5.0, 2.5.1, 2.5.2
> Reporter: Maxim Kuzmin
> Assignee: Adriano dos Santos Fernandes
> Priority: Minor
>
> Example:
> EXECUTE BLOCK
> RETURNS (ID INTEGER NOT NULL)
> AS
> BEGIN
> END
> When executing this query, FB raised error:
> The insert failed because a column definition includes validation constraints.
> validation error for variable ID, value "*** null ***".
> But there not insert's! There just empty recordset.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
