> FROM [SQL Statemet]. As Alias
That's Jet 3.5 isn't it? I think Jet 4.0 is different.
(david)
"David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
news:Xns96C9C6B4A85B1dfentonbwaynetinvali@216.196. 97.142...[color=blue]
> "Ryan" <ryanofford@hotmail.com> wrote in
> news:1125907637.410398.109020@z14g2000cwz.googlegr oups.com:
>[color=green]
>> It IS a join and is a perfectly legal SQL statement, . . .[/color]
>
> Well, I'm certainly no SQL expert, but it's not joining two tables
> by matching values in two fields in the respective tables, so the
> use of the word "JOIN" makes little sense to me, even if there are
> SQL dialects that support it.
>[color=green]
>> . . . although MS
>> Access does not allow it. Adding this to the 'where' clause is the
>> easy and normal route to take. If this was examined in detail (in
>> both Access and SQL) then it would show that having this in the
>> where clause excludes the data I need in the left join too early
>> in the execution process and therefore does not show this in the
>> result set. In effect, this excludes certain data and renders a
>> left join defunct in this instance.[/color]
>
> Well, then, use nested SQL. Replace the table in the FROM clause
> with a SQL statement that filters the table you're trying to filter.
> In most SQL dialects you need only surround that SQL statement with
> parentheses, but Access has its own idiosyncratic format:
>
> FROM [SQL Statemet]. As Alias
>
> (and the alias can be the same as the name of underlying table
> you're filteringn so that the SELECT will remain valid)
>
> The only problem is that the SQL inside the brackets cannot itself
> include any brackets. If you've used spaces or non-alphanumeric
> characters in field/table names, then this won't work.
>
> I don't know the official name for this technique, but I call it a
> "virtual table."
>
> --
> David W. Fenton
http://www.bway.net/~dfenton
> dfenton at bway dot net
http://www.bway.net/~dfassoc[/color]