>> Thanks Martijn for your comments. Looking forward to Jason's
>> notes. Russell
> So am I.
> Jason, are you around?
> I have to continue bugging you about this :-)

I can probably add some notes, since Jason did ask if I could
help in this area - but lack of time has meant that (so far) I
have been unable to provide any real assistance. (I bugged
Jason about some of these issues many months ago :-)

Jason has already fixed many FB2 issues in the latest releases
of IBObjects. Such things as the predefined queries used by
IB_SQL and also the metadata caching queries etc.

The big one, or so it seems to me, is trying to rework much of
the IBObjects automation surrounding SQL parsing. In
particular, in regard to searching and other automated SQL
construction.

The issue here is that IBObjects offers great automated SQL
construction to provide automatic search queries and some other
features in IBO. This automation will often not work with FB2
because of the new requirement that aliases are used throughout
any given query.

The change in FB2 is both good and bad in respect to IBO. IBO
has always had some short-fall with its automation in respect
to self-referencing queries (tree structures), and the new
feature of FB2 would allow IBO to solve those problems. OTOH
FB2 effectively breaks IBO in many existing applications
because it insists that this new feature should fully
implemented in all applications - so many existing IBObjects
applications will simply not function in FB2 (including most
of my own).


My own personal opinion is that the FB development team have
made a mistake... They released a change with no intermdiate
supporting step. That is;

Prior to FB2 there was no API mechanism to discover the alias
defined to a relation. So automation, such as that provided by
IBObjects in building of search queries, necessarily had to use
the relation name to uniquely identify fields, even if aliases
existed in the original query.

They then released FB2 that REQUIRED the use of aliases
throughout the query, and now have finally provided the API
support to discover a relation alias (or so I believe, I have
not studied the API changes yet). Both changes together, one
dependent on the other.

The better alternative IMHO would have been to release the
alias API change first, to give libraries a chance to update,
and then in a later release require the alias to be used.

But too late for that now. So...


We now have to work out how to make IBO function with these
new restrictions. This involves several things.

Firstly, in order to continue supporting older versions where
the API does not provide relation aliases, IBO needs to
continue functioning as it does now.

Secondly, when it detects FB2 or later (I dont know about IB)
it must extend its API support to load the alias information.

Thirdly... well this is the hard part. What can we break in
order to make things work.

If IBO did not care about existing applications it would
simply change its "BestFieldName" and "FullFieldName" column
properties to return "alias"."field_name" (where alias is
available, and "relation"."field_name" otherwise). Doing this
would break existing apps until they are updated to use any
defined alias, but doing this one change may well solve many of
the FB2 compatibility issues.

This one change would also require some cooperation from the
developer when creating relationships... more below.

I am not sure how clear I am being here.

Previously, in any complex query, it has been necessary to
supply field references as "relation_name"."field_name". As
such a great many applications have many such references spread
through DFMs, code and so on. (This I expect will need to
include master links and all the other various *Links and
*Fields properties.) It is quite possible that existing base
queries were written using aliases (I know that many of mine
were). So any change which began to return BestFieldName as
the alias will break all those references, and they would need
fixing before they work with the updated IBO.

And then we hit master/detail relationships, and in particular
the great feature of IBObjects to support searching in forms
even when master/detail relationships exist. When search
criteria is entered against a detail dataset IBO automatically
constructs the search query using an EXISTS test. This query
has so far used relation names to ensure ambiguities between
the same column names are avoided. In FB2 aliases must be used
always if any defined in any queries, and so the existing IBO
automation must make special preparation. It must...

- either reconstruct the entire queries using its own
relation alias names (which means effectively building
an entire SQL parser engine to completely decomponse a
query - it only partially does so right now)
or
- demand that developers use consistent aliases between
related queries.

I would like to suggest the second option, as being both easier
for IBO to support and more consistent when monitoring via the
SQL monitor and similar tools.

Example of BAD/INCORRECT use:

master query:
SELECT * FROM ATABLE T
detail query:
SELECT * FROM BTABLE T
(and suitable MasterLinks)

In pre-FB2 IBO IBO is happy with this arrangement (if given
appropriate MasterLinks) because it will build a search against
the master as something like:
SELECT * FROM ATABLE T
WHER EXISTS(SELECT * FROM BTABLE
WHERE BTABLE.FK = ATABLE.PK AND
BTABLE.XFIELD = 'SOME VALUE')

In FB2 this will fail because the alias T has not been used
consistently throughout the query.

We, as application developers, can help make the conversion to
an FB2 compatible IBObjects version by agreeing that we will
write our queries like this...

Example of GOOD/CORRECT use:

master query:
SELECT * FROM ATABLE A
detail query:
SELECT * FROM BTABLE B

By using *different* aliases in every detail query (different
from each other and different from the master) we can allow
IBObjects to simply alter its BestFieldName to always return
the alias and know that it will give an adequate automated SQL
query to search and similar items.

Are we, IBObjects users, willing to make this committment to
an IBO/FB2 release?

Note what I said earlier. If you want a version of IBObjects
that is FB2 compatible without changing your existing apps,
then this will mean waiting for IBO to (effectively) build a
full SQL parser so that it can decomponse and then reconstruct
queries with their own aliases to ensure that they are unique.
This will not be easy and will take a lot of work (and so a lot
of time), and I doubt that it is truly practical.

Any thoughts from others?

Disclaimer: These are my own thoughts, Jason may have others.

--
Geoff Worboys
Telesis Computing