The default is ansi_null on? On Thu, Oct 2, 2008 at 10:48 PM, Tapio Kulmala <[EMAIL PROTECTED]>wrote:
> > Exactly. > > <quote> > Transact-SQL supports an extension that allows for the comparison > operators to return TRUE or FALSE when comparing against null values. > This option is activated by setting ANSI_NULLS OFF. When ANSI_NULLS is > OFF, comparisons such as ColumnA = NULL return TRUE when ColumnA > contains a null value and FALSE when ColumnA contains some value > besides NULL. > </quote> > > > You said that foo = null is always false and NHB delegates the check > to the database and that It will work if you set ansi_null off. > > IMHO, That would only work if ansi_nulls is on. > > Am I missing something important and making fool of myself? > > Tapio > > > On Oct 2, 10:18 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
