Subject | Re: [Firebird-Architect] Fetching from a non-cursor |
---|---|
Author | Jim Starkey |
Post date | 2010-10-15T16:27:28Z |
I never said it was the original design. On the contrary, procedures
weren't even part of the original design. Stored procedures were hacked
in by Borland.
I don't care what it does. I do care that arbitrary changes don't break
existing applications. That's all. Well, not quite all. I also don't
believe in putting lipstick on a pig.
weren't even part of the original design. Stored procedures were hacked
in by Borland.
I don't care what it does. I do care that arbitrary changes don't break
existing applications. That's all. Well, not quite all. I also don't
believe in putting lipstick on a pig.
On 10/15/2010 11:09 AM, Dimitry Sibiryakov wrote:
> 15.10.2010 16:59, Alex Peshkoff wrote:
>> What we started to discuss is 'Is the fact that isc_dsql_execute()
>> agrees to work with EXECUTE PROCEDURE a bug or documented behavior?'
> And everybody except Jim agreed that this is a bug.
> Jim insists that this was original design. If Jim is right, first fetch from EXECUTE
> PROCEDURE must return data and subsequent ones - 100.
> However, in this case one question left: what if the procedure is selectable (i.e. uses
> SUSPEND)? Shouldn't in this case all records be fetched before end-of-data and EXECUTE
> PROCEDURE to be effectively the same as SELECT?
>
--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376