Hi Leila,
Long answer:
SQL Server keeps the semantic equivalent of a bitswitch to determine whether
a value is database NULL. If you write a UDT, you keep the semantic
equivalent of a bitswitch (determined by the implementor, you) and answer
correctly to IsNull (a read-only) property. SQL Server can optimize by
reading its bitswitch and not having to instanciate one of your UDTs just to
find out that its NULL. It will do this on (instance) method calls if the
method is not marked InvokeIfReceiverIsNull=true. SQL Server does not set
your "nullability bit" directly, there is no set method on IsNull.
In your statement:
set @p = '1:1'
SQL Server calls Parse (to convert from string) and you make a non-null
instance, "setting it to non-null as far as your IsNull implementation is
concerned" in your code. SQL Server calls your IsNull property as part of
this statement, setting its internal bitswitch.
In your statement:
if @p IS NULL...
SQL Server does not necesarily have to call your IsNull at all, if it
"knows" (through its bitswitch) the value is NULL. Be careful with this, as
this T-SQL statement:
SELECT @p.IsNull
returns false or NULL unless InvokeIfReceiverIsNull=true is specified on the
IsNull accessor. Then, it would return false or true. I've written a few
blog entries about this too. ;-)
Cheers,
Bob Beauchemin
http://www.SQLskills.com/blogs/bobb
"Leila" <Leilas@hotpop.com> wrote in message
news:epZ6SM3HGHA.216@TK2MSFTNGP15.phx.gbl...
|