At 03:46 PM 3/07/2003 -0700, you wrote:

> > SELECT SINGULAR would in fact be the "most right" kind of select query to
> > use in this case, since it won't return any exceptions. All you'd have to
> > do is the equivalent of an IsEmpty test on Fields[], right? What would
> > that test be? since TIB_DSQL doesn't have the BOF and EOF properties...
>
>I don't think SINGULAR is a keyword that goes in the statement if that's
>what you are implying by the caps. There is no test with TIB_DSQL. You
>either get information from one row back or an exception.

The reason why I suggested it as the right one, is that SELECT SINGULAR
returns either one row or no rows. You don't get an exception because, if
the output evaluates to > 1 row, the SINGULAR requirement is not met, and
you get no rows back at all.

> > Users will still need to know that this applies only to Firebird 1.5 and
> > later, until (or unless) the fix is backported in the Firebird 1.0.4
> > subrelease...
>
>I can't remember exactly when this fix was introduced. It may also be in
>Firebird 1.x. It had to do with the SQLDa buffer in the client getting
>scrambled due to a variable that got bumped around instead of staying
>dedicated to one statement context.

It's a 1.5 fix that happened since the code on which the 1.0.3 subrelease
was built. Some further backporting is proposed for the final 1.0.x
release (1.0.4). I strongly recommend that you put your hand up to get
this particular fix backported. The person looking after the backporting
is Paul Reeves.

At the time the fix was discussed, there was even conjecture about whether
the fix would mess up interfaces like IBO, which provide workarounds for
the messed-up column orders in the legacy engines.

Helen