At 04:34 AM 10/05/2005 +0000, you wrote:

>Hi Hellen,
>
>I goofed. I just made your suggested changes and compiled it with my
>old version of Marathon (v1.6) and it compiled. I was then talking to
>my wife about what you had suggested and I started thinking that your
>changes shouldn't have made any difference. So I went through and
>tried my original code in Marathon (v1.6) and everything compiled.
>
>So my problem lies with Marathon (v3.0.0.50) and not necessarily with
>my code.
>
>Although I can see where your coming from I still think that, from a
>logic pov, my original code should work without confusing the database
>engine. So I'll ask again, because I'm now wondering what kind of
>consequences my original code could have vs. your explicit code, why
>would the explicit table naming make any difference for the select on
>the IN clause. Wouldn't the brackets provide enough logical
>seperation for the engine to properly determine what columns are
>coming from which tables?

It's not a question of what you think is logical (or not) but how the
optimizer handles it. The purpose of the changes was to prevent syntax
that doesn't comply with the standard and thus (as a bonus) avoid
generating sets that aren't what you thought they ought logically to
be. You used to get away with a lot of things pre-1.5. v.1.5 is less
tolerant. When you get to v.2, your statement will choke.

Good idea to read the release notes if you're working on tool apps? Start
with the 1.5 notes and move on to the v.2 alpha notes.

./hb