In this case, like all null handling, NH leaves the decision to the DB
semantics.On the face of it, is looks like it is doing the appropriate
thing.
On Wed, Oct 1, 2008 at 12:52 PM, Thomas Koch <[EMAIL PROTECTED]> wrote:
>
> Hi - I am using NH 2.0 against SQL Server 2005.
>
> I am comparing two properties from different classes using the
> Restrictions.NotEqProperty method of the criteria API and everything
> is working like a charm. That all changed when I suddenly encountered
> null values.
>
> A fragment of my query:
>
> Disjunction disjunction = new Disjunction();
> disjunction.
> .Add(Restrictions.NotEqProperty("f.Owner", "s.Owner"))
> .Add(Restrictions.NotEqProperty("f.Name", "s.Name")) ...
>
> This results in the following SQL fragment:
> ...
> not this_0_.Owner = this_.Owner or
> not this_0_.Name = this_.Name or
> ...
>
> What happens is that when s.Owner for instance is NULL and f.Owner is
> not null then "this_0_.Owner = this_.Owner" still evaluates to true on
> the SQL Server.
>
> My instincts now tell med that comparing NULLs with non-NULL values is
> something that is vendor specific.
>
> But looking at the Restrictions.NotEqProperty I would have expected it
> to handle this issue.
>
> Can anyone suggest an alternative?
>
> Kind regards,
> Thomas
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
