Subject RES: [ib-support] Re: Found possible bug on FB 1.0 build 821
Author Fernando Deola

Actually I was not trying to convince anybody that my original query
offers the best way for doing that. Instead, I only put that scenario
under discussion and, fortunately, you agree that the related led to a
FB bug. First round won.

Now, for the second: I think that even though that is not a 'good'
query, that construction should work, otherwise, in the future, we'll
have to take on hands two manuals: one for constructing selects and the
other for constructing sub-selects... See? I believe it will be more
consistent to maintain the syntax in all cases, so, I guess raising an
error seems to be the worst option. But it's just a guess...



Fernando Deola
EFEX Systems Ltda.
Blumenau - SC - Brasil

-----Mensagem original-----
De: Svein Erling Tysv?r [mailto:svein.erling.tysvaer@...]

Enviada em: sexta-feira, 20 de setembro de 2002 18:38
Assunto: [ib-support] Re: Found possible bug on FB 1.0 build 821

>I thought that even without an order specified, the engine is supposed
>to use the natural one. As Oracle has its ROWID, I think FB has its
>RDB$DBKEY (or something like that) that is generated after the
>insertions and stablished some order. So, if in regular selects I use
>obtain the same result set (in natural order) why not in subselects?
>Aren't the rows returned in a top-down sequence, according to the
>information in the system tables?

You are right Fernando, FB has rdb$db_key and it is constant for the
duration of your transaction
( explains it very
And you have convinced me that it is indeed a bug - although I am not
certain whether the fix should be to cater for FIRST/SKIP within the
subselect or raise an error at compile time saying that FIRST/SKIP in a
subselect is not allowed (you have not convinced me that your original
is a good way to do what you tried to do).


To unsubscribe from this group, send an email to:

Your use of Yahoo! Groups is subject to