Are you sure about this? Thomas said :
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.
Tapio
On Oct 2, 9:12 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> It will work if you set ansi_null off, nothing in NHibernate assumes this.
> But the system is setup to handle the case where this is not the scenario
>
> On Thu, Oct 2, 2008 at 9:05 PM, Tapio Kulmala <[EMAIL PROTECTED]>wrote:
>
>
>
> > Thanks Oren!
>
> > If NHibernate assumes that foo = null is always false, it means that
> > everybody should use "ansi_nulls on". Otherwise the assumption is
> > false. Am I right?
>
> > Tapio
>
> > On Oct 2, 8:33 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> > > NHibernate follows the SQL model. In general, the behavior is that foo =
> > > null is always false.It does so by delegating to the DB, but we are
> > > explicitly providing IsNull and IsNotNull for the purpose of null
> > > comparisions.
>
> > > On Thu, Oct 2, 2008 at 6:22 PM, Tapio Kulmala <[EMAIL PROTECTED]
> > >wrote:
>
> > > > Hi Thomas!
>
> > > > This is an interesting issue. You probably have ansi_nulls off in your
> > > > database. That setting changes dramatically the behavior of null-
> > > > comparisons. You can test it easily in northwind database
>
> > > > set ansi_nulls on
> > > > select * from orders where not shippeddate = null
> > > > select * from orders where not shippeddate is null
>
> > > > set ansi_nulls off
> > > > select * from orders where not shippeddate = null
> > > > select * from orders where not shippeddate is null
>
> > > > Oren, Fabio, anybody....
>
> > > > What's the recommended setting with NHibernate? Does NHibernate create
> > > > ANSI compatible null checks / SQL?
>
> > > > Tapio
>
> > > > On Oct 1, 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
-~----------~----~----~----~------~----~------~--~---
