Roger,

> From: rogervellacott [mailto:rvellacott@...]
> Sent: Thursday, December 06, 2001 12:42 PM

> > First, Firebird RC2 'loosens' the ambiguity issues, if only
> slightly.
>
> Oh good. But it sounds like not enough.

You know, if you don't like something with Firebird your more than
welcome pull up your sleeves and get your hands dirty yourself -- I'm
sure that Claudio V. would appreciate the assistance.

Until then, your comments are appreciated and will be considered...

> Are you recommending then that we should stay with Dialect 1?

No, you should be moving to dialect 3, but dialect 3 is a stricker
environment. When and how you will get there is up to you.

> I had rather assumed that this would eventually be phased out.

While I don't know when dialect 1/2 will be dropped, it is a safe bet to
say that it will happen.

The engine code is already 'black hole of Calculta ugly' with old ports,
unused features and other c**p, the sooner we can drop the dialect thing
from the engine, IMHO, the better as well.

> > 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?

The reason that Firebird added ambiguity checking was the result of
Claudio noting some significant errors/inconsistencies in the treatment
of certain queries.

We did not go out of our way to create problems for people, but at the
same time to have the engine produce inconsistent results, is just NOT
acceptable.

> > > 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?

We don't allow for user to type-in their own queries, we present a GUI
which allows them to drag and drop columns for there query -- so there
is no possibity of ambiguity.

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

As you can tell, not as much as you would like ;-)


Sean