Hi Dany,

> The solution should be the one that caters for best practices
> in the future. A funny workaround to allow legacy applications
> right away will probably backfire later when writing more
> advanced applications.

I am not sure what you consider to be a "funny workaround".

What I would like to know is; Will people accept the following
restriction/limitation for FB2 support in IBObjects...

If relation aliases are to be used in queries, that all related
queries (master/detail and main/lookup) would use their own
separate/different relation alias (or no alias), and so be able
to avoid conflicts in automatically generated SQL that may
combine details from each query.

(Note: I am not sure if the alias situation will effect IBO's
implementation of lookups, in most cases I suspect not. But it
will definitely impact master/detail relationships and so the
use of different aliases would be required.)

By requiring developers to use relation aliases in this way
(rather than requiring IBO to decompose the SQL so that it can
rebuild with its own aliases) I believe we can alter IBO to
support FB2 more easily. I dont see this as an overly onerous
requirement, but I wonder how others see it.

--
Geoff Worboys
Telesis Computing