http://msdn.microsoft.com/en-us/library/aa196339.aspx
On Thu, Oct 2, 2008 at 9:22 PM, Tapio Kulmala <[EMAIL PROTECTED]>wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
