Subject RE: [IBO] Stored proc question
Author Claudio Valderrama C.
> -----Original Message-----
> From: Helen Borrie [mailto:helebor@...]
> Sent: Martes 29 de Mayo de 2001 10:44
> At 03:39 PM 29-05-01 +0200, you wrote:
> > >>Do I have to do a close and a Unprepare every
> > >>time it's executed again ?
> >
> > > Yes, unfortunately, with executable stored procedures
> > > you do, because of a bug in the API function, that
> > > fails to clear a field in that structure after execution.
> >
> >Has the Firebird team fixed that one? In which version?
> No, it has been assigned a very low priority (demoted from 5 to 9
> on Feb. 20). See bug 0233025. Go in there and nag at Sean Leyne
> about it!

I know I will sound harsh, but I'm in good humor, so don't misinterpret me,
- Usually, bug reports that cannot be reproduced are either demoted or
- Maybe if the bug didn't come from a reliable source (Jason) it would have
been closed.
- Dynamic data manipulation is IMHO the most complex part of the engine. You
go into streams, rivers and other implementation terminology and may end up
drowning in the ocean. I tracked a problem with views and quoted identifiers
only to come to the conclusion that a brute force approach would be to run
two debuggers at the same time, one with the failing statement and other
with the equivalent statement that doesn't use quoted identifiers. Since two
IBs cannot run on the same NT machine, I would have to add VMWare in the
tale. A clueless debug would take at least 5 hours. The other approach is to
enable some conditional code and get a low-level log. Whether this log is
thorough and can be read by normal humans is another tale.
- I don't remember if the glitch has been mentioned in the context of IBX or
- Months ago, I asked in this same list for a failing example. I mean, an
example that works but showing the failure. I only got directions. I asked
more and more to no avail. After spending more than 8 hours trying different
combinations, I gave up: the bug never showed. Hence, to be crude, the first
step for getting a chance to see the bug fixed is to provide a reproducible
- I didn't notice Sean has lowered the priority. Most of the current FB
developers are on Linux, UNIX or *BSD (and also on Darwin-Mac). Our Win32
specialist (Mike) uses MSVC. IMHO, Sean doesn't use IBO and Helen doesn't
use MSVC. This narrows the options to either Paul Reeves, Reed Mideke or me,
but they don't use IBO so the arrow seems to be pointing at me. <g> I debug
with MSVC but I need a small example (the briefer, the better) that compiles
with D3: the smallest number of input parameters, the smallest number of
output parameters, the smallest procedure body and the minimal number of
times the thing should be run to observe the bug, coupled with clear
instructions: should it be run on another machine than the server? Can it be
observed on the same machine using TCP? Can it be reproduced using a local
connection to the server in NT? Is only TCP affected or should I use NetBEUI
- On the other side, using a TIB_Cursor to do a SELECT and including a
SUSPEND statement in the proc is so easy and will avoid the re-preparing
overhead of the workaround that I can understand Sean.

Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente -