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
-~----------~----~----~----~------~----~------~--~---
