On 25/08/2017 11:06, Paul Reeves wrote:
> On Fri, 25 Aug 2017 14:00:03 +0300 Dmitry Yemanov wrote
>
>>> But whatever happened to the SP debugger?
>> AFAIK, it was never started (although was discussed a bit).
>>
> And while on the subject of a debugger for SPs...
>
> There are commercial Stored
On Fri, 25 Aug 2017 14:00:03 +0300 Dmitry Yemanov wrote
>
> > But whatever happened to the SP debugger?
>
> AFAIK, it was never started (although was discussed a bit).
>
And while on the subject of a debugger for SPs...
There are commercial Stored Procedure debuggers available. And I've
25.08.2017 13:06, Paul Reeves wrote:
Is there a simple hack I could do to build FB3.0 with the plan enabled
for SPs?
Not so simple, as the code was completely refactored. I will try to
provide you with a patch during the next days.
But whatever happened to the SP debugger?
AFAIK, it was
On Fri, 25 Aug 2017 12:28:17 +0300 Dmitry Yemanov wrote
>
> I agree it was handy in simple cases, but it had too many conceptual
> problems.
I accept that for all but the most simple cases the 'plan' was more or
less useless. But just seeing PLAN (NATURAL) is extremely frustrating.
Is
25.08.2017 11:38, Paul Reeves wrote:
In FB 3.0 the plan output for stored procs is always PLAN (NATURAL)
whereas with FB 2.5 the plan for each sql statement to be executed
within the SP are returned.
Not having the plan available in FB 3.0 makes it quite difficult to see
what is actually
In FB 3.0 the plan output for stored procs is always PLAN (NATURAL)
whereas with FB 2.5 the plan for each sql statement to be executed
within the SP are returned.
Not having the plan available in FB 3.0 makes it quite difficult to see
what is actually happening in the SP. However, if we take any
