I've just come across a bug where the order in date comparisons is critical:

DateTime? dateValue ...
q = q.Where(d => dateValue.Value >= d.MyDate);

This gets reordered in the generated SQL which is fine but the >= becomes < [LPA_L2].[MyDate] < @MyDate20

If you reorder the lambda expression, everything is fine: q = q.Where(d => d.MyDate <= dateValue.Value);

I haven't tried to see if this symptom appears with other data types.

Please post the runtime library build you're using (see guidelines thread in this forum), e.g. 2.8.07.0709

I see where it goes wrong. The thing the Linq provider has to deal with is that it has to convert to our own predicate classes. These work with a Field and then an operator and a value for example. The binary expression datetime.Value >= field has the field as the right side operand, while the FieldCompareValue predicate wants it to have as the left side operand. So it swaps operands. Of course, the operator also has to swap in that case.

The mistake is in the operand chosen . Swapping >= is of course <=, not <. There are more: < swapped becomes >= which of course isn't correct: if an 'equal' component is in the operator, the swapped version also has to have that.

Fixed in next build.