Subject | AW: [IBO] IBO 4.7.16 wrong update SQL with alias |
---|---|
Author | hsenner |
Post date | 2007-05-01T06:45:58Z |
I have realized this problem as well. Indeed it has to do with the parsing
of the underlying
SQL statement within the IBF_Query.pas unit. I have changed the code just
recently in a
way that avoids parsing but works with IB_Row properties (as the query
always had to be
prepared also for the "parsing" way, it is no overhead) which is less prone
to parsing errors.
I've not yet sent these changes to Jason because I wanted to add some
additional capabilities
to the query editor.
Working with the editor during the last days (concerning the Edit-SQLs)
seemed to be
correctly under all circumstances (queries with or without aliases with or
without joins; the
Firebird version doesn't matter as the parsing is done in the "deeper
spheres" of IBO).
If you are interested I can send you my IBF_Query.pas (or to Helen or Jason
respectively
for a common access).
Herbert
_____
Von: sentto-402930-3142-1177982560-hsenner=web.de@...
[mailto:sentto-402930-3142-1177982560-hsenner=web.de@...
m] Im Auftrag von Helen Borrie
Gesendet: Dienstag, 1. Mai 2007 03:24
An: IBObjects@yahoogroups.com
Betreff: Re: [IBO] IBO 4.7.16 wrong update SQL with alias
At 08:37 AM 1/05/2007, Rade wrote:
correct in your usage of table aliases. You cannot, for example, use
a table name for one table and an alias for another; or refer to a
table in one place by its name and in another by its alias. Also, if
you omit the qualifier on any _field reference_ in a multi-table
query, you will get unexpected XxxSQL generated by IBO. Look
particularly at ".*" and your WHERE, ORDER BY and GROUP BY clauses,
where IB and Fb have allowed slackness in the past.
Then, at Prepare time, your SELECT statement will except with
Firebird 2.x if you have not followed the aliasing rules
correctly. As far as I know, IB has not cleaned up in this area yet
and does not return relation aliases in the interface structures...I
believe the IBO changes take this into account and make it so that
the missing RelationAlias member does not cause an AV. However, it
expects you to follow the correct syntax rules even though IB still
allows the bad syntax.
Helen
[Non-text portions of this message have been removed]
of the underlying
SQL statement within the IBF_Query.pas unit. I have changed the code just
recently in a
way that avoids parsing but works with IB_Row properties (as the query
always had to be
prepared also for the "parsing" way, it is no overhead) which is less prone
to parsing errors.
I've not yet sent these changes to Jason because I wanted to add some
additional capabilities
to the query editor.
Working with the editor during the last days (concerning the Edit-SQLs)
seemed to be
correctly under all circumstances (queries with or without aliases with or
without joins; the
Firebird version doesn't matter as the parsing is done in the "deeper
spheres" of IBO).
If you are interested I can send you my IBF_Query.pas (or to Helen or Jason
respectively
for a common access).
Herbert
_____
Von: sentto-402930-3142-1177982560-hsenner=web.de@...
[mailto:sentto-402930-3142-1177982560-hsenner=web.de@...
m] Im Auftrag von Helen Borrie
Gesendet: Dienstag, 1. Mai 2007 03:24
An: IBObjects@yahoogroups.com
Betreff: Re: [IBO] IBO 4.7.16 wrong update SQL with alias
At 08:37 AM 1/05/2007, Rade wrote:
>Hi all,Could you provide an exact example of the SELECT statement?
>
>I have a problem with generating inset, update and delete statements
>with Generate for Table button. If i use an alias for table sql
>generated is totaly wrong (eveything is ok if i don't use an alias).
>IIt could be so; but the parser changes require you to be completely
>also noticed that use an alias menuitem does not work on a pop-up
>menu. You can click on it as much as you like but state doesn't
>change. It does not metter if i use Interbase 7 or Firebird 2.0.1 it
>workes the same way. So, i suppose that there is something in IBO code.
correct in your usage of table aliases. You cannot, for example, use
a table name for one table and an alias for another; or refer to a
table in one place by its name and in another by its alias. Also, if
you omit the qualifier on any _field reference_ in a multi-table
query, you will get unexpected XxxSQL generated by IBO. Look
particularly at ".*" and your WHERE, ORDER BY and GROUP BY clauses,
where IB and Fb have allowed slackness in the past.
Then, at Prepare time, your SELECT statement will except with
Firebird 2.x if you have not followed the aliasing rules
correctly. As far as I know, IB has not cleaned up in this area yet
and does not return relation aliases in the interface structures...I
believe the IBO changes take this into account and make it so that
the missing RelationAlias member does not cause an AV. However, it
expects you to follow the correct syntax rules even though IB still
allows the bad syntax.
Helen
[Non-text portions of this message have been removed]