Roger,

First, Firebird RC2 'loosens' the ambiguity issues, if only slightly.

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.

> 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 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 ;-)

> 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. ;-)


Sean