Hi,

> > I've been thinking a little about it and it seems we need an exact
> > string compare here, one that takes only complete 'words' and not
> > just parts of them... A bit more intelligence needed than just Pos
> > ... there are some small catches to it :)
>
> We can do that - but it would not solve all possible problems.
> Remember that the select statement can actually get very complicated
> (aliases, embedded selects etc).

pff - you're right about that ... it does get more complicated :(

> The difficulty is that this has to be done before the prepare (so that
> the field can be added if necessary). Which is a pity, because after
> prepare we have an ready list of column names to scan :-(

Yes, I noticed - this is where the exception gets raised :)

> One thing you may be able to offer your opinion towards...
>
> We may be able to improve the current situation reasonably easily
> (doing a word match as you suggested) - is this sufficient or do we
> really have to go all the way and do our own parsing of the select
> statement to accurately discover all field names ???

What about an option to allways add DB_KEY to the outer select,
and if this is True, not use auto-key-links at all? This way, we can
have an updateable resultset in an easy way ( as I understand from
Claudios documets ) for even the more complex statements... Right?



--
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com

Upscene Productions
http://www.upscene.com

"This is an object-oriented system.
If we change anything, the users object."