Subject | IB_Parse.GetSQLFirstAndSkip bug (IBO 4.6 B) |
---|---|
Author | yovchoz |
Post date | 2006-06-13T10:18:29Z |
Hello,
I have a TIBOQuery component opening a query returning some fields
having the string 'FIRST' as a part of field name. Calling
the 'Refresh'
method for that query every time raises the following exception:
ISC ERROR CODE:335544569
ISC ERROR MESSAGE:
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, char 23
.
I found the source of problem into the GetSQLFirstAndSkip function.
It incorrectly founds the 'FIRST' substring of field name as a SQL
FIRST
keyword. Also, it looks very sensitive to arrangement of the SQL.
For example, the following query:
select
rdb$relations.rdb$relation_id
, rdb$relations.rdb$dbkey_length as FIELD_FIRST
, rdb$relations.rdb$system_flag as FIELD_1
from rdb$relations
will raise an exception, but the following will not:
select
rdb$relations.rdb$relation_id,
rdb$relations.rdb$dbkey_length as FIELD_FIRST,
rdb$relations.rdb$system_flag as FIELD_1
from rdb$relations
I found a workaround changing the last parameter ("TokenOnly")
from "false" to "true" for both calls to getLitsRoundSafeStrPos,
seems fixed the problem, but I'm not sure can I expect a side
effects?
I have a TIBOQuery component opening a query returning some fields
having the string 'FIRST' as a part of field name. Calling
the 'Refresh'
method for that query every time raises the following exception:
ISC ERROR CODE:335544569
ISC ERROR MESSAGE:
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, char 23
.
I found the source of problem into the GetSQLFirstAndSkip function.
It incorrectly founds the 'FIRST' substring of field name as a SQL
FIRST
keyword. Also, it looks very sensitive to arrangement of the SQL.
For example, the following query:
select
rdb$relations.rdb$relation_id
, rdb$relations.rdb$dbkey_length as FIELD_FIRST
, rdb$relations.rdb$system_flag as FIELD_1
from rdb$relations
will raise an exception, but the following will not:
select
rdb$relations.rdb$relation_id,
rdb$relations.rdb$dbkey_length as FIELD_FIRST,
rdb$relations.rdb$system_flag as FIELD_1
from rdb$relations
I found a workaround changing the last parameter ("TokenOnly")
from "false" to "true" for both calls to getLitsRoundSafeStrPos,
seems fixed the problem, but I'm not sure can I expect a side
effects?