Tapio Kulmala [EMAIL PROTECTED] writes:
You said that foo = null is always false
Yes, he said that, but he didn't mean it. :)
This whole thread is another example of why it's a big design fault to
ever include NULL into SQL. Three valued logic is just not for
everyone.
As the cited link said:
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
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
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
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
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
Found the answer.
The default used to be (sql 2000) ansi_nulls off. In SQL server 2008
the database option is deprecated and the default value is on.
Tapio
On Oct 2, 10:56 pm, Ayende Rahien [EMAIL PROTECTED] wrote:
The default is ansi_null on?
On Thu, Oct 2, 2008 at 10:48 PM, Tapio
Hi Ayende - thank you for your reply. :-)
When I think about this issue from an object perspective I find that
the Restrictions.NotEqProperty should have dealt with this. I
interpret it as comparing two object references in C#. But I can
understand the problems involved if the database has a
Thomas, something happening with your mails... each time you post something
3 mails arrive to the list.
First in uNhAddIns and now in Burrow.AppBlock you have EqOrNullExpression
with no extra work.
Bye.
Fabio Maulo
--~--~-~--~~~---~--~~
You received this message
