--- In ib-support@y..., "Leyne, Sean" <sleyne@a...> wrote:

> Roger,
>
> First, Firebird RC2 'loosens' the ambiguity issues, if only

slightly.

Oh good. But it sounds like not enough.

>
> In the case of Dialect 1 databases, the system will raise a warning

(for

> those software tools which are prepared to listen for them) but will
> allow the query to execute.
>
> For Dialects 2 & 3, the system will error and abort the query.
>

Are you recommending then that we should stay with Dialect 1? I had
rather assumed that this would eventually be phased out.

>
> > I would rather have ambiguity, than have to rewrite every query

in

> > our apps. It is not a matter of sloppy code. It is a matter of
> > flexibility.
>
> Ambiguity == inconsistent results == bad!
>

I assumed that Dialect 1 and IB used the first occurence of the field
name in the list of field names in the query. This is not
inconsistent. Are you telling me it sometimes chooses the first
occurrence, and at other times second or third occurrences?

>
> > I want my users to be able to write their own report queries, and

to

> > be able sort all their screens by clicking on a column heading,

and

> > to be able to create filter clauses by selecting from a field

list

> > etc etc.
>
> Our own application has the same type of feature, the only

difference is

> that we've designed ours to include an alias name for all

table/column

> references. It would seem that you just need to improve the
> 'intelligence' of your tool ;-)
>

My tool (mostly encapsulated in a DBGrid derivative) is able to
accept aliases and prefixes, and any hard-coded query can work quite
happily. However, users are able to write their own queries for
reporting and data-exporting purposes, and view the results in a
grid, and it is not so easy to know which table their fields came
from. How do you manage this with your tool?

>
> > Why can't RC1 do its best to understand the query, and maybe give

a

> > warning if there is ambiguity, and run it anyway.
>
> The issue is that not many tools are actually designed to listen

for the

> warnings.
>
>
> > Leave it up to the developer to remove ambiguity.
>
> The new 'ginder/gentler' approach for dialect 1 database is

intended to

> give developer that latitude/breathing room.
>
>
> > This is IMPORTANT. Is there anyone out there who agrees with me?
>
> Yes, it's important but I don't agree completely. ;-)
>

But it sounds like you agree mostly, which is good.

>
> Sean