At 10:07 AM 14/10/2003 +0000, you wrote:

>Tim,
>
> > There's a problem in your SQL string. What does the SQL string hold at
> > this stage?
>
>Well, as I said in my initaial post - the SQL I put in is really so
>simple it couldn't be any simpler.
>
>I put in this:
>
>SELECT FIRST 1 * FROM Table WHERE (ID = 1)
>
>But the Prepare call managed to transform my input into this:
>
>SELECT FIRST 1 *
> , Table.RDB$DB_KEY
>FROM Table WHERE (ID = 1)
>
>Incidentally, I checked and this error pops up even if I remove the
>WHERE portion, leaving just this:
>
>SELECT FIRST 1 * FROM Table
>
>I believe this must be IBO's fault, because this very same statement
>works like a charm with IBX (checked) and IB Expert (also checked).
>
>However, with IBO, I can reproduce the exception even at design time,
>by opening the IBOQuery's SQL editor, typing in the above SQL
>statement and clicking the Prepare button.

Confirmed: there's a parsing bug there, affecting all dataset
components. The SQL as parsed doesn't work in ISQL either.
This does:
SELECT FIRST 1 Table.*
, Table.RDB$DB_KEY
FROM Table WHERE (ID = 1)

IOW, the parser should use the table identifier right across. (It doesn't
work in ISQL with no table identifier).

Your SQL will work with IBX and with IBExpert, because neither of them
makes use of the db_key.

So, to avoid the parsing bug, you have a few choices:
1. Fix up your keylinks so that IBO doesn't need to query for the rdb$db_key
or
2. Present the corrected SQL yourself (as example above)
or
3. Use the Raw SQL prefix ::SQL:: on your statement (which will get you a
non-updatable return set)

Helen




Helen