rather based on an expression (e.g. a function).
The effects of such a JOIN? If the expression involved transformations (e.g.
functions on predicates) then the Query Optimizer would not be able to take
advantage of any otherwise appropriate indexes when retrieveing data.
Have you compared the execution plans of the original vs. the "corrected"
queries?
ML wrote:
> Fx designates that the JOIN is not based on a simple column comparison but
> rather based on an expression (e.g. a function).
Function/expression: That is what I thought first.
But the query onlz "consists" of the three lines I marked in the code,
which are each AND or OR - expansions of a JOIN clause stated before.
Maybe it is the OR part that makes the code an expression rather
than keeping a simple column comparison.
What I guess the join "does" is something like this:
...
-- do a join between ZP and ZpVe (only when) ...
LEFT OUTER JOIN dbo.Zaehlpunkte_Versorgung_Strom ZpVe
ON ZP.Zaehlpunkte_Key = ZpVe.Zaehlpunkte_key
-- ... these fields of VeZpZuO and ZpVe match <=
AND VeZpZuO.Datum_von <= ZpVe.Datum_Versorgungsbeginn
-- ... and the follwing complex AND / OR condition is met
AND (VeZpZuO.Datum_bis IS NULL -- THIS LINE IS PART OF THE FX - JOIN
AND ZpVe.Datum_Versorgungsende IS NULL -- AND ALSO THIS ONE
OR VeZpZuO.Datum_bis >= ZpVe.Datum_Versorgungsbeginn) -- AND ALSO THIS ONE
...
My intellectual problem is that the conditions and clauses are so distributed over
several tables, even tables which are different to those to which the grafical
connection end points are connected to.
Can someone describe this join better than I tried in the snippet above?
Joachim