At 10:11 PM 18/09/2007, you wrote:

>Hello!
>
> I'm using D7 + FB1.5 + IBO4.8.7, and a strange situation is
>happening. For example, this statement:
>
> SELECT SP.COL1, SP.COL2 FROM MY_PROCEDURE SP
>
> IBO raises an error: "Cannot select RDB$DB_KEY from a stored
>procedure". Well, with IBExpert works fine and with IBO4.3.Aa, too.
>After I removed the aliases from statement, it works.
>
> SELECT COL1, COL2 FROM MY_PROCEDURE
>
> or
>
> SELECT * FROM MY_PROCEDURE
>
> Strange, uh?
>
> I really appreciate some help,

The world has changed since IBO 4.3a! Specifically, now Firebird 2
returns relation aliases for multi-table selects and IBO turns
cartwheels to accommodate it. The "cost" is that some questionable
syntaxes that were harmless previously can now upset IBO. You have
provided a relation alias for a select on a single SP without
defining Keylinks. While assembling the facts it needs in order to
request a Prepare for a multi-table select statement, IBO finds there
are no Keylinks so it falls back (as it always did) on attempting to
use the db_key to assure uniqueness of rows. It reads the cached
metadata, finds that MY_PROCEDURE isn't a table (and therefore has no
db_key) and so raises an exception. It's not weird, it's as designed.

If you want to use an alias for a selectable SP make sure you turn
off KeyLinksAutoDefine and explicitly provide accurate Keylinks for the set.

FWIW, IBExpert is based on FIBPlus, which doesn't care whether sets
have rows with duplicate keys, since it doesn't have the features
that IBO has, like searching, RefreshRows, refresh positioning
options, live datasets, etc., that Keylinks are needed for.

Helen