> > There's really not much to it - the problem seemed easy
> > reproducable to me.
>
> What was that about "assuming"?? ;-)

Yep, shame on me ;-)

> ...
> > for employee, tmpStr will turn up EMP_NO - if I select FIRST_NAME,
> > there's no way that pos(tmpStr, SQLSelectStr) = 0 -> so, keylinks
> > get cleared, DB_KEY gets added
>
> > But, for SELECT RELOAD_ID FROM IA_REPORT_RELOAD -
> > tmpStr will become ID (PK column) and Pos(tmpStr, SQLSelectStr)
> > gives pos > 0 ----> no keylinks clear, no DB_KEY added --> error...
>
> Yep that all makes sense. I was thinking this was the area of the
> code most likely to be causing problems, but just by looking at it I
> was not certain what was wrong. Its pretty obvious now that you point
> it out with an example.
>
> ...
> > Geoff, I hope you can reproduce the error as easy as me with the
> > above DDL and we both get the error at the same position in code - I
> > guess we can find a way to fix it now...
>
> I think there may be some utility functions in IB_Parse that can help
> us out in this situation. I will investigate further now that I know
> how to reproduce.

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


--
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."