|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
C# Nullable typeshi,
i'm a new bie to c#.net 2.0.... i've come across a new feature by name nullable types...need some info on it what is actually a null value... what exactly is advantage we get by specifying a value type as a null value... please clarify For example for a price it would allow to distingusih between something that
is free (0) and something for which don't know the price (null). It's likely you'll mostly use this for dates (if the vetn occured the date will be filled, if the event didnt' occured date, the date will be null). --- Patrice "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news: 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...Show quote > hi, > i'm a new bie to c#.net 2.0.... > i've come across a new feature by name nullable types...need some info on > it > > what is actually a null value... > what exactly is advantage we get by specifying a value type as a null > value... > > please clarify I would have to disagree with your analogy.
If someting is free, it still has a value of zero dollars (as you say), but if we don't know the price, that doesn't make the price null, it just makes the price unkown. null is simply a keyword that indicates that the item in question does not have a relationship to any data at all. A = 0 <-- A has a value of zero A = " " <-- A has a value of the space char A = "" <-- A has a null value (no data at all) The benefit of null values is primarially when using databases, since most databases have tables where not all fields are required to have a value (like a middle name or apartment number or name suffix, such as Sr. or Jr.). Since it is possible that a field may be null, we need a way of checking it as such or passing null values into it. -Scott Show quote "Patrice" <http://www.chez.com/scribe/> wrote in message news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl... > For example for a price it would allow to distingusih between something > that is free (0) and something for which don't know the price (null). > > It's likely you'll mostly use this for dates (if the vetn occured the date > will be filled, if the event didnt' occured date, the date will be null). > > --- > Patrice > > "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news: > 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com... >> hi, >> i'm a new bie to c#.net 2.0.... >> i've come across a new feature by name nullable types...need some info on >> it >> >> what is actually a null value... >> what exactly is advantage we get by specifying a value type as a null >> value... >> >> please clarify > > Scott M. <s-mar@nospam.nospam> wrote:
> I would have to disagree with your analogy. That much I'd agree with.> > If someting is free, it still has a value of zero dollars (as you say), but > if we don't know the price, that doesn't make the price null, it just makes > the price unkown. > > null is simply a keyword that indicates that the item in question does not > have a relationship to any data at all. > A = 0 <-- A has a value of zero That particular example is a bit confusing, as the string literal "" > A = " " <-- A has a value of the space char > A = "" <-- A has a null value (no data at all) and null are very different. One is a reference to a 0-length string, the other is a reference to no object at all. So I'd say that "" has data - it has the data that it's an empty string. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Not sure what you meant. How would you mark that the price is unknown if not
using a "nullable" type representing a null value ? As a side note, an empty string is not a "null" string (in the first case we known that the value is a zero length string, in the other case we don't know what the value is). IMO one of the problem in discussing is that null has multiple acceptances. In the context of a nullable type this is the same than the "NULL" (Il'l use uppercase for this meaning) marker used in most DB, not the "null" refererence as usual in C# (likely why MS used HasValue for what is called "nullable" types toa void the ambiguity). VB.NET uses the Nothing keyword. Finally I see sometimes what is IMO an abusive use of NULL. If you know that you have no name suffix, you don't have to use a NULL value but an empty string will do. You have to use a NULLable column if you want to distinguish if the value is an empty string or if it has no meaning (i.e. not "known", "applicable" or whatever semantic you attribute to the NULL value). --- Patrice "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...Show quote >I would have to disagree with your analogy. > > If someting is free, it still has a value of zero dollars (as you say), > but if we don't know the price, that doesn't make the price null, it just > makes the price unkown. > > null is simply a keyword that indicates that the item in question does not > have a relationship to any data at all. > > A = 0 <-- A has a value of zero > A = " " <-- A has a value of the space char > A = "" <-- A has a null value (no data at all) > > The benefit of null values is primarially when using databases, since most > databases have tables where not all fields are required to have a value > (like a middle name or apartment number or name suffix, such as Sr. or > Jr.). Since it is possible that a field may be null, we need a way of > checking it as such or passing null values into it. > > -Scott > > "Patrice" <http://www.chez.com/scribe/> wrote in message > news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl... >> For example for a price it would allow to distingusih between something >> that is free (0) and something for which don't know the price (null). >> >> It's likely you'll mostly use this for dates (if the vetn occured the >> date will be filled, if the event didnt' occured date, the date will be >> null). >> >> --- >> Patrice >> >> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news: >> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com... >>> hi, >>> i'm a new bie to c#.net 2.0.... >>> i've come across a new feature by name nullable types...need some info >>> on it >>> >>> what is actually a null value... >>> what exactly is advantage we get by specifying a value type as a null >>> value... >>> >>> please clarify >> >> > > Something having an unknown value is not, in any way, related to a
dissussion of null. The very word you use "unkown" implies that there is, in fact, something to "know". A null value indicates the exact opposite of that, that there is no value at all. That's why I said that your alaogy was not a good one. When I run into situations where a value is unknown to me, I set up a variable to capture that value. After doing that, I can then look to see if the varialbe is null, seven, "green" or anything else. The fact that I didn't know the value of the variable does not imply null. You seem to be discussing what a "nullable type" is, rather than the meaning of "null". Show quote "Patrice" <http://www.chez.com/scribe/> wrote in message news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl... > Not sure what you meant. How would you mark that the price is unknown if > not using a "nullable" type representing a null value ? As a side note, an > empty string is not a "null" string (in the first case we known that the > value is a zero length string, in the other case we don't know what the > value is). > > IMO one of the problem in discussing is that null has multiple > acceptances. In the context of a nullable type this is the same than the > "NULL" (Il'l use uppercase for this meaning) marker used in most DB, not > the "null" refererence as usual in C# (likely why MS used HasValue for > what is called "nullable" types toa void the ambiguity). VB.NET uses the > Nothing keyword. > > Finally I see sometimes what is IMO an abusive use of NULL. If you know > that you have no name suffix, you don't have to use a NULL value but an > empty string will do. You have to use a NULLable column if you want to > distinguish if the value is an empty string or if it has no meaning (i.e. > not "known", "applicable" or whatever semantic you attribute to the NULL > value). > --- > Patrice > > > "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: > %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl... >>I would have to disagree with your analogy. >> >> If someting is free, it still has a value of zero dollars (as you say), >> but if we don't know the price, that doesn't make the price null, it just >> makes the price unkown. >> >> null is simply a keyword that indicates that the item in question does >> not have a relationship to any data at all. >> >> A = 0 <-- A has a value of zero >> A = " " <-- A has a value of the space char >> A = "" <-- A has a null value (no data at all) >> >> The benefit of null values is primarially when using databases, since >> most databases have tables where not all fields are required to have a >> value (like a middle name or apartment number or name suffix, such as Sr. >> or Jr.). Since it is possible that a field may be null, we need a way of >> checking it as such or passing null values into it. >> >> -Scott >> >> "Patrice" <http://www.chez.com/scribe/> wrote in message >> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl... >>> For example for a price it would allow to distingusih between something >>> that is free (0) and something for which don't know the price (null). >>> >>> It's likely you'll mostly use this for dates (if the vetn occured the >>> date will be filled, if the event didnt' occured date, the date will be >>> null). >>> >>> --- >>> Patrice >>> >>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news: >>> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com... >>>> hi, >>>> i'm a new bie to c#.net 2.0.... >>>> i've come across a new feature by name nullable types...need some info >>>> on it >>>> >>>> what is actually a null value... >>>> what exactly is advantage we get by specifying a value type as a null >>>> value... >>>> >>>> please clarify >>> >>> >> >> > > OK I perhaps see a bit better your semantic point. AFAIK some additional
"markers" were suggested in SQL standards to better define various meanings of "undefined", "unknown"," not applicable" or several other semantics given to NULL values but never made into products... I perhaps miss also some nuances as English is not my native language but hopefull the overall picture should be clear enough for the OP. "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl...Show quote > Something having an unknown value is not, in any way, related to a > dissussion of null. The very word you use "unkown" implies that there is, > in fact, something to "know". A null value indicates the exact opposite > of that, that there is no value at all. That's why I said that your > alaogy was not a good one. > > When I run into situations where a value is unknown to me, I set up a > variable to capture that value. After doing that, I can then look to see > if the varialbe is null, seven, "green" or anything else. The fact that I > didn't know the value of the variable does not imply null. > > You seem to be discussing what a "nullable type" is, rather than the > meaning of "null". > > > > > "Patrice" <http://www.chez.com/scribe/> wrote in message > news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl... >> Not sure what you meant. How would you mark that the price is unknown if >> not using a "nullable" type representing a null value ? As a side note, >> an empty string is not a "null" string (in the first case we known that >> the value is a zero length string, in the other case we don't know what >> the value is). >> >> IMO one of the problem in discussing is that null has multiple >> acceptances. In the context of a nullable type this is the same than the >> "NULL" (Il'l use uppercase for this meaning) marker used in most DB, not >> the "null" refererence as usual in C# (likely why MS used HasValue for >> what is called "nullable" types toa void the ambiguity). VB.NET uses the >> Nothing keyword. >> >> Finally I see sometimes what is IMO an abusive use of NULL. If you know >> that you have no name suffix, you don't have to use a NULL value but an >> empty string will do. You have to use a NULLable column if you want to >> distinguish if the value is an empty string or if it has no meaning (i.e. >> not "known", "applicable" or whatever semantic you attribute to the NULL >> value). >> --- >> Patrice >> >> >> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl... >>>I would have to disagree with your analogy. >>> >>> If someting is free, it still has a value of zero dollars (as you say), >>> but if we don't know the price, that doesn't make the price null, it >>> just makes the price unkown. >>> >>> null is simply a keyword that indicates that the item in question does >>> not have a relationship to any data at all. >>> >>> A = 0 <-- A has a value of zero >>> A = " " <-- A has a value of the space char >>> A = "" <-- A has a null value (no data at all) >>> >>> The benefit of null values is primarially when using databases, since >>> most databases have tables where not all fields are required to have a >>> value (like a middle name or apartment number or name suffix, such as >>> Sr. or Jr.). Since it is possible that a field may be null, we need a >>> way of checking it as such or passing null values into it. >>> >>> -Scott >>> >>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl... >>>> For example for a price it would allow to distingusih between something >>>> that is free (0) and something for which don't know the price (null). >>>> >>>> It's likely you'll mostly use this for dates (if the vetn occured the >>>> date will be filled, if the event didnt' occured date, the date will be >>>> null). >>>> >>>> --- >>>> Patrice >>>> >>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news: >>>> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com... >>>>> hi, >>>>> i'm a new bie to c#.net 2.0.... >>>>> i've come across a new feature by name nullable types...need some info >>>>> on it >>>>> >>>>> what is actually a null value... >>>>> what exactly is advantage we get by specifying a value type as a null >>>>> value... >>>>> >>>>> please clarify >>>> >>>> >>> >>> >> >> > > Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not
applicable" have never been identified with "null" in SQL or anywhere else. When I mark a filed in SQL as "nullable", I am not doing it because I don't know what value the user may want to put into the field. On the contrary, I do it because I'm letting the user not put any value at all into the field. Again "undefined", "unknown"," not applicable" does not equal "null". I think this is super-important to be clear on, because "null" has a special purpose and meaning and the minute you try to attach a meaning that is something similiar, but not the same, to it, you confuse the issue and make it more complicated than it need be. Show quote "Patrice" <http://www.chez.com/scribe/> wrote in message news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl... > OK I perhaps see a bit better your semantic point. AFAIK some additional > "markers" were suggested in SQL standards to better define various > meanings of "undefined", "unknown"," not applicable" or several other > semantics given to NULL values but never made into products... > > I perhaps miss also some nuances as English is not my native language but > hopefull the overall picture should be clear enough for the OP. > > > "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: > ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl... >> Something having an unknown value is not, in any way, related to a >> dissussion of null. The very word you use "unkown" implies that there >> is, in fact, something to "know". A null value indicates the exact >> opposite of that, that there is no value at all. That's why I said that >> your alaogy was not a good one. >> >> When I run into situations where a value is unknown to me, I set up a >> variable to capture that value. After doing that, I can then look to see >> if the varialbe is null, seven, "green" or anything else. The fact that >> I didn't know the value of the variable does not imply null. >> >> You seem to be discussing what a "nullable type" is, rather than the >> meaning of "null". >> >> >> >> >> "Patrice" <http://www.chez.com/scribe/> wrote in message >> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl... >>> Not sure what you meant. How would you mark that the price is unknown if >>> not using a "nullable" type representing a null value ? As a side note, >>> an empty string is not a "null" string (in the first case we known that >>> the value is a zero length string, in the other case we don't know what >>> the value is). >>> >>> IMO one of the problem in discussing is that null has multiple >>> acceptances. In the context of a nullable type this is the same than the >>> "NULL" (Il'l use uppercase for this meaning) marker used in most DB, not >>> the "null" refererence as usual in C# (likely why MS used HasValue for >>> what is called "nullable" types toa void the ambiguity). VB.NET uses the >>> Nothing keyword. >>> >>> Finally I see sometimes what is IMO an abusive use of NULL. If you know >>> that you have no name suffix, you don't have to use a NULL value but an >>> empty string will do. You have to use a NULLable column if you want to >>> distinguish if the value is an empty string or if it has no meaning >>> (i.e. not "known", "applicable" or whatever semantic you attribute to >>> the NULL value). >>> --- >>> Patrice >>> >>> >>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl... >>>>I would have to disagree with your analogy. >>>> >>>> If someting is free, it still has a value of zero dollars (as you say), >>>> but if we don't know the price, that doesn't make the price null, it >>>> just makes the price unkown. >>>> >>>> null is simply a keyword that indicates that the item in question does >>>> not have a relationship to any data at all. >>>> >>>> A = 0 <-- A has a value of zero >>>> A = " " <-- A has a value of the space char >>>> A = "" <-- A has a null value (no data at all) >>>> >>>> The benefit of null values is primarially when using databases, since >>>> most databases have tables where not all fields are required to have a >>>> value (like a middle name or apartment number or name suffix, such as >>>> Sr. or Jr.). Since it is possible that a field may be null, we need a >>>> way of checking it as such or passing null values into it. >>>> >>>> -Scott >>>> >>>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl... >>>>> For example for a price it would allow to distingusih between >>>>> something that is free (0) and something for which don't know the >>>>> price (null). >>>>> >>>>> It's likely you'll mostly use this for dates (if the vetn occured the >>>>> date will be filled, if the event didnt' occured date, the date will >>>>> be null). >>>>> >>>>> --- >>>>> Patrice >>>>> >>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news: >>>>> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com... >>>>>> hi, >>>>>> i'm a new bie to c#.net 2.0.... >>>>>> i've come across a new feature by name nullable types...need some >>>>>> info on it >>>>>> >>>>>> what is actually a null value... >>>>>> what exactly is advantage we get by specifying a value type as a null >>>>>> value... >>>>>> >>>>>> please clarify >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > I'm not using null when "I don't know what value the user may want to input"
(actually I never know what value the user will enter, not sure what you meant). Also I don't use NULL when "I'm letting the user not put any value at all into the field" which is IMO bad form at least to do systematically. I'll use an empty string or 0 as a default value if it makes senses. I will use this for example for the actual start date of something that not started yet. In this case you can't provide any value. IMO this is a more convincing sample than Appartement number and the like where in a real world scenario you never want to distinguish between a value that can't be provided for some reason (null) and the fact that the apartment number is just an empty string because you *know* this is an empty string, not because you are unable to provide this value. This is perhaps why I tried at first to explain what's behind null. I felt that using simply the word "null" was perhaps not sufficient as it is IMO sometimes misused. --- Patrice "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: OTi6AT4dHHA.1***@TK2MSFTNGP04.phx.gbl...Show quote > Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not > applicable" have never been identified with "null" in SQL or anywhere > else. When I mark a filed in SQL as "nullable", I am not doing it because > I don't know what value the user may want to put into the field. On the > contrary, I do it because I'm letting the user not put any value at all > into the field. > > Again "undefined", "unknown"," not applicable" does not equal "null". I > think this is super-important to be clear on, because "null" has a special > purpose and meaning and the minute you try to attach a meaning that is > something similiar, but not the same, to it, you confuse the issue and > make it more complicated than it need be. > > > "Patrice" <http://www.chez.com/scribe/> wrote in message > news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl... >> OK I perhaps see a bit better your semantic point. AFAIK some additional >> "markers" were suggested in SQL standards to better define various >> meanings of "undefined", "unknown"," not applicable" or several other >> semantics given to NULL values but never made into products... >> >> I perhaps miss also some nuances as English is not my native language but >> hopefull the overall picture should be clear enough for the OP. >> >> >> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl... >>> Something having an unknown value is not, in any way, related to a >>> dissussion of null. The very word you use "unkown" implies that there >>> is, in fact, something to "know". A null value indicates the exact >>> opposite of that, that there is no value at all. That's why I said that >>> your alaogy was not a good one. >>> >>> When I run into situations where a value is unknown to me, I set up a >>> variable to capture that value. After doing that, I can then look to >>> see if the varialbe is null, seven, "green" or anything else. The fact >>> that I didn't know the value of the variable does not imply null. >>> >>> You seem to be discussing what a "nullable type" is, rather than the >>> meaning of "null". >>> >>> >>> >>> >>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl... >>>> Not sure what you meant. How would you mark that the price is unknown >>>> if not using a "nullable" type representing a null value ? As a side >>>> note, an empty string is not a "null" string (in the first case we >>>> known that the value is a zero length string, in the other case we >>>> don't know what the value is). >>>> >>>> IMO one of the problem in discussing is that null has multiple >>>> acceptances. In the context of a nullable type this is the same than >>>> the "NULL" (Il'l use uppercase for this meaning) marker used in most >>>> DB, not the "null" refererence as usual in C# (likely why MS used >>>> HasValue for what is called "nullable" types toa void the ambiguity). >>>> VB.NET uses the Nothing keyword. >>>> >>>> Finally I see sometimes what is IMO an abusive use of NULL. If you know >>>> that you have no name suffix, you don't have to use a NULL value but an >>>> empty string will do. You have to use a NULLable column if you want to >>>> distinguish if the value is an empty string or if it has no meaning >>>> (i.e. not "known", "applicable" or whatever semantic you attribute to >>>> the NULL value). >>>> --- >>>> Patrice >>>> >>>> >>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >>>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl... >>>>>I would have to disagree with your analogy. >>>>> >>>>> If someting is free, it still has a value of zero dollars (as you >>>>> say), but if we don't know the price, that doesn't make the price >>>>> null, it just makes the price unkown. >>>>> >>>>> null is simply a keyword that indicates that the item in question does >>>>> not have a relationship to any data at all. >>>>> >>>>> A = 0 <-- A has a value of zero >>>>> A = " " <-- A has a value of the space char >>>>> A = "" <-- A has a null value (no data at all) >>>>> >>>>> The benefit of null values is primarially when using databases, since >>>>> most databases have tables where not all fields are required to have a >>>>> value (like a middle name or apartment number or name suffix, such as >>>>> Sr. or Jr.). Since it is possible that a field may be null, we need a >>>>> way of checking it as such or passing null values into it. >>>>> >>>>> -Scott >>>>> >>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl... >>>>>> For example for a price it would allow to distingusih between >>>>>> something that is free (0) and something for which don't know the >>>>>> price (null). >>>>>> >>>>>> It's likely you'll mostly use this for dates (if the vetn occured the >>>>>> date will be filled, if the event didnt' occured date, the date will >>>>>> be null). >>>>>> >>>>>> --- >>>>>> Patrice >>>>>> >>>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de >>>>>> news: 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com... >>>>>>> hi, >>>>>>> i'm a new bie to c#.net 2.0.... >>>>>>> i've come across a new feature by name nullable types...need some >>>>>>> info on it >>>>>>> >>>>>>> what is actually a null value... >>>>>>> what exactly is advantage we get by specifying a value type as a >>>>>>> null value... >>>>>>> >>>>>>> please clarify >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > I think you are making my point here. You introduced the concepts and
terms: "unknown", "undefined" and "not applicable" into the disussion. In addition, you are talking about "why" a database needs the concept of a null (I personally think you mis-stated that, but that is besides the point). Below, you are talking about the practical use of null, rather than the meaning of null, which is the point of this thread. Show quote "Patrice" <http://www.chez.com/scribe/> wrote in message news:ecXux94dHHA.4032@TK2MSFTNGP02.phx.gbl... > I'm not using null when "I don't know what value the user may want to > input" (actually I never know what value the user will enter, not sure > what you meant). > > Also I don't use NULL when "I'm letting the user not put any value at all > into the field" which is IMO bad form at least to do systematically. I'll > use an empty string or 0 as a default value if it makes senses. > > I will use this for example for the actual start date of something that > not started yet. In this case you can't provide any value. IMO this is a > more convincing sample than Appartement number and the like where in a > real world scenario you never want to distinguish between a value that > can't be provided for some reason (null) and the fact that the apartment > number is just an empty string because you *know* this is an empty string, > not because you are unable to provide this value. > > This is perhaps why I tried at first to explain what's behind null. I felt > that using simply the word "null" was perhaps not sufficient as it is IMO > sometimes misused. > > --- > Patrice > > "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: > OTi6AT4dHHA.1***@TK2MSFTNGP04.phx.gbl... >> Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not >> applicable" have never been identified with "null" in SQL or anywhere >> else. When I mark a filed in SQL as "nullable", I am not doing it because >> I don't know what value the user may want to put into the field. On the >> contrary, I do it because I'm letting the user not put any value at all >> into the field. >> >> Again "undefined", "unknown"," not applicable" does not equal "null". I >> think this is super-important to be clear on, because "null" has a >> special purpose and meaning and the minute you try to attach a meaning >> that is something similiar, but not the same, to it, you confuse the >> issue and make it more complicated than it need be. >> >> >> "Patrice" <http://www.chez.com/scribe/> wrote in message >> news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl... >>> OK I perhaps see a bit better your semantic point. AFAIK some additional >>> "markers" were suggested in SQL standards to better define various >>> meanings of "undefined", "unknown"," not applicable" or several other >>> semantics given to NULL values but never made into products... >>> >>> I perhaps miss also some nuances as English is not my native language >>> but hopefull the overall picture should be clear enough for the OP. >>> >>> >>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >>> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl... >>>> Something having an unknown value is not, in any way, related to a >>>> dissussion of null. The very word you use "unkown" implies that there >>>> is, in fact, something to "know". A null value indicates the exact >>>> opposite of that, that there is no value at all. That's why I said >>>> that your alaogy was not a good one. >>>> >>>> When I run into situations where a value is unknown to me, I set up a >>>> variable to capture that value. After doing that, I can then look to >>>> see if the varialbe is null, seven, "green" or anything else. The fact >>>> that I didn't know the value of the variable does not imply null. >>>> >>>> You seem to be discussing what a "nullable type" is, rather than the >>>> meaning of "null". >>>> >>>> >>>> >>>> >>>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>>> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl... >>>>> Not sure what you meant. How would you mark that the price is unknown >>>>> if not using a "nullable" type representing a null value ? As a side >>>>> note, an empty string is not a "null" string (in the first case we >>>>> known that the value is a zero length string, in the other case we >>>>> don't know what the value is). >>>>> >>>>> IMO one of the problem in discussing is that null has multiple >>>>> acceptances. In the context of a nullable type this is the same than >>>>> the "NULL" (Il'l use uppercase for this meaning) marker used in most >>>>> DB, not the "null" refererence as usual in C# (likely why MS used >>>>> HasValue for what is called "nullable" types toa void the ambiguity). >>>>> VB.NET uses the Nothing keyword. >>>>> >>>>> Finally I see sometimes what is IMO an abusive use of NULL. If you >>>>> know that you have no name suffix, you don't have to use a NULL value >>>>> but an empty string will do. You have to use a NULLable column if you >>>>> want to distinguish if the value is an empty string or if it has no >>>>> meaning (i.e. not "known", "applicable" or whatever semantic you >>>>> attribute to the NULL value). >>>>> --- >>>>> Patrice >>>>> >>>>> >>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >>>>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl... >>>>>>I would have to disagree with your analogy. >>>>>> >>>>>> If someting is free, it still has a value of zero dollars (as you >>>>>> say), but if we don't know the price, that doesn't make the price >>>>>> null, it just makes the price unkown. >>>>>> >>>>>> null is simply a keyword that indicates that the item in question >>>>>> does not have a relationship to any data at all. >>>>>> >>>>>> A = 0 <-- A has a value of zero >>>>>> A = " " <-- A has a value of the space char >>>>>> A = "" <-- A has a null value (no data at all) >>>>>> >>>>>> The benefit of null values is primarially when using databases, since >>>>>> most databases have tables where not all fields are required to have >>>>>> a value (like a middle name or apartment number or name suffix, such >>>>>> as Sr. or Jr.). Since it is possible that a field may be null, we >>>>>> need a way of checking it as such or passing null values into it. >>>>>> >>>>>> -Scott >>>>>> >>>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>>>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl... >>>>>>> For example for a price it would allow to distingusih between >>>>>>> something that is free (0) and something for which don't know the >>>>>>> price (null). >>>>>>> >>>>>>> It's likely you'll mostly use this for dates (if the vetn occured >>>>>>> the date will be filled, if the event didnt' occured date, the date >>>>>>> will be null). >>>>>>> >>>>>>> --- >>>>>>> Patrice >>>>>>> >>>>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de >>>>>>> news: 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com... >>>>>>>> hi, >>>>>>>> i'm a new bie to c#.net 2.0.... >>>>>>>> i've come across a new feature by name nullable types...need some >>>>>>>> info on it >>>>>>>> >>>>>>>> what is actually a null value... >>>>>>>> what exactly is advantage we get by specifying a value type as a >>>>>>>> null value... >>>>>>>> >>>>>>>> please clarify >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > I will just end with how the SQL Server doc explains this.
http://msdn2.microsoft.com/en-us/library/ms191504.aspx : "Null values generally indicate data that is unknown, not applicable, or that the data will be added later." I'm not sure what is the point you don't like in this definition that looks quite close to mine but it really looks like that understanding each other on this topic is out of reach. Take care and see you soon in another thread for another heated discussion ;-) -- Patrice "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: OMPOZW5dHHA.4***@TK2MSFTNGP02.phx.gbl...Show quote >I think you are making my point here. You introduced the concepts and >terms: "unknown", "undefined" and "not applicable" into the disussion. In >addition, you are talking about "why" a database needs the concept of a >null (I personally think you mis-stated that, but that is besides the >point). > > Below, you are talking about the practical use of null, rather than the > meaning of null, which is the point of this thread. > > > "Patrice" <http://www.chez.com/scribe/> wrote in message > news:ecXux94dHHA.4032@TK2MSFTNGP02.phx.gbl... >> I'm not using null when "I don't know what value the user may want to >> input" (actually I never know what value the user will enter, not sure >> what you meant). >> >> Also I don't use NULL when "I'm letting the user not put any value at all >> into the field" which is IMO bad form at least to do systematically. I'll >> use an empty string or 0 as a default value if it makes senses. >> >> I will use this for example for the actual start date of something that >> not started yet. In this case you can't provide any value. IMO this is a >> more convincing sample than Appartement number and the like where in a >> real world scenario you never want to distinguish between a value that >> can't be provided for some reason (null) and the fact that the apartment >> number is just an empty string because you *know* this is an empty >> string, not because you are unable to provide this value. >> >> This is perhaps why I tried at first to explain what's behind null. I >> felt that using simply the word "null" was perhaps not sufficient as it >> is IMO sometimes misused. >> >> --- >> Patrice >> >> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >> OTi6AT4dHHA.1***@TK2MSFTNGP04.phx.gbl... >>> Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," >>> not applicable" have never been identified with "null" in SQL or >>> anywhere else. When I mark a filed in SQL as "nullable", I am not doing >>> it because I don't know what value the user may want to put into the >>> field. On the contrary, I do it because I'm letting the user not put >>> any value at all into the field. >>> >>> Again "undefined", "unknown"," not applicable" does not equal "null". I >>> think this is super-important to be clear on, because "null" has a >>> special purpose and meaning and the minute you try to attach a meaning >>> that is something similiar, but not the same, to it, you confuse the >>> issue and make it more complicated than it need be. >>> >>> >>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>> news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl... >>>> OK I perhaps see a bit better your semantic point. AFAIK some >>>> additional "markers" were suggested in SQL standards to better define >>>> various meanings of "undefined", "unknown"," not applicable" or several >>>> other semantics given to NULL values but never made into products... >>>> >>>> I perhaps miss also some nuances as English is not my native language >>>> but hopefull the overall picture should be clear enough for the OP. >>>> >>>> >>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >>>> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl... >>>>> Something having an unknown value is not, in any way, related to a >>>>> dissussion of null. The very word you use "unkown" implies that there >>>>> is, in fact, something to "know". A null value indicates the exact >>>>> opposite of that, that there is no value at all. That's why I said >>>>> that your alaogy was not a good one. >>>>> >>>>> When I run into situations where a value is unknown to me, I set up a >>>>> variable to capture that value. After doing that, I can then look to >>>>> see if the varialbe is null, seven, "green" or anything else. The >>>>> fact that I didn't know the value of the variable does not imply null. >>>>> >>>>> You seem to be discussing what a "nullable type" is, rather than the >>>>> meaning of "null". >>>>> >>>>> >>>>> >>>>> >>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>>>> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl... >>>>>> Not sure what you meant. How would you mark that the price is unknown >>>>>> if not using a "nullable" type representing a null value ? As a side >>>>>> note, an empty string is not a "null" string (in the first case we >>>>>> known that the value is a zero length string, in the other case we >>>>>> don't know what the value is). >>>>>> >>>>>> IMO one of the problem in discussing is that null has multiple >>>>>> acceptances. In the context of a nullable type this is the same than >>>>>> the "NULL" (Il'l use uppercase for this meaning) marker used in most >>>>>> DB, not the "null" refererence as usual in C# (likely why MS used >>>>>> HasValue for what is called "nullable" types toa void the ambiguity). >>>>>> VB.NET uses the Nothing keyword. >>>>>> >>>>>> Finally I see sometimes what is IMO an abusive use of NULL. If you >>>>>> know that you have no name suffix, you don't have to use a NULL value >>>>>> but an empty string will do. You have to use a NULLable column if you >>>>>> want to distinguish if the value is an empty string or if it has no >>>>>> meaning (i.e. not "known", "applicable" or whatever semantic you >>>>>> attribute to the NULL value). >>>>>> --- >>>>>> Patrice >>>>>> >>>>>> >>>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >>>>>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl... >>>>>>>I would have to disagree with your analogy. >>>>>>> >>>>>>> If someting is free, it still has a value of zero dollars (as you >>>>>>> say), but if we don't know the price, that doesn't make the price >>>>>>> null, it just makes the price unkown. >>>>>>> >>>>>>> null is simply a keyword that indicates that the item in question >>>>>>> does not have a relationship to any data at all. >>>>>>> >>>>>>> A = 0 <-- A has a value of zero >>>>>>> A = " " <-- A has a value of the space char >>>>>>> A = "" <-- A has a null value (no data at all) >>>>>>> >>>>>>> The benefit of null values is primarially when using databases, >>>>>>> since most databases have tables where not all fields are required >>>>>>> to have a value (like a middle name or apartment number or name >>>>>>> suffix, such as Sr. or Jr.). Since it is possible that a field may >>>>>>> be null, we need a way of checking it as such or passing null values >>>>>>> into it. >>>>>>> >>>>>>> -Scott >>>>>>> >>>>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>>>>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl... >>>>>>>> For example for a price it would allow to distingusih between >>>>>>>> something that is free (0) and something for which don't know the >>>>>>>> price (null). >>>>>>>> >>>>>>>> It's likely you'll mostly use this for dates (if the vetn occured >>>>>>>> the date will be filled, if the event didnt' occured date, the date >>>>>>>> will be null). >>>>>>>> >>>>>>>> --- >>>>>>>> Patrice >>>>>>>> >>>>>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de >>>>>>>> news: 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com... >>>>>>>>> hi, >>>>>>>>> i'm a new bie to c#.net 2.0.... >>>>>>>>> i've come across a new feature by name nullable types...need some >>>>>>>>> info on it >>>>>>>>> >>>>>>>>> what is actually a null value... >>>>>>>>> what exactly is advantage we get by specifying a value type as a >>>>>>>>> null value... >>>>>>>>> >>>>>>>>> please clarify >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > I will just end with how the SQL Server doc explains this. I really like that definition. It feels closest to what I think it should > > http://msdn2.microsoft.com/en-us/library/ms191504.aspx : > > "Null values generally indicate data that is unknown, not applicable, > or that the data will be added later." mean. -- Rory But (again) that is SQL definition of what a null value *indicates*, not of
what a the *definition* of null is. It is also limited to SQL, not the .NET Framework. This documentation essentially says "Use null as an indication of the following separate and different things...". That, in no way is a defition of what null represents. Wouldn't you agree that "an unknown value" could be a value of 27? Is 27 null? So, I would say that the documentation is actually poorly written (wouldn't be the first time). Show quote "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message news:b0ac48a083368c945bfa70ac670@msnews.microsoft.com... >> I will just end with how the SQL Server doc explains this. >> >> http://msdn2.microsoft.com/en-us/library/ms191504.aspx : >> >> "Null values generally indicate data that is unknown, not applicable, >> or that the data will be added later." > > I really like that definition. It feels closest to what I think it should > mean. > > -- > Rory > > If you don't know the value, you don't know it is 27 so you'll have a
"null" value anyway as you can't do better. Once you know the value is 27, you'll have 27. I don't see how it would make 27 equal to null. Looks like as simple as that to me. Of course if you wanted to distinguish additional cases ("not know", "not applicable" etc...) you would have to keep an additional value acting as a marker but I've never have to do this myself until then. My understanding is that the OP wasn't discussing the null C# keyword but the 2.0 "nullable types" feature (http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to mark a value type as being "null"? I would be very inclined to think that it were precisely introduced to match the NULL marker found DBMS sidea nd that wasn't available .NET side for value types until now. Finally I would think he was expecting a bit more than a "formal definition" (what is yours ?) but sorry we are not allowed to tell you what this value could "indicate" in practice in your code... I have nothing to add... -- Patrice "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: uH02rU6dHHA.3***@TK2MSFTNGP03.phx.gbl...Show quote > But (again) that is SQL definition of what a null value *indicates*, not > of what a the *definition* of null is. It is also limited to SQL, not the > .NET Framework. > > This documentation essentially says "Use null as an indication of the > following separate and different things...". That, in no way is a > defition of what null represents. > > Wouldn't you agree that "an unknown value" could be a value of 27? Is 27 > null? So, I would say that the documentation is actually poorly written > (wouldn't be the first time). > > > > > "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message > news:b0ac48a083368c945bfa70ac670@msnews.microsoft.com... >>> I will just end with how the SQL Server doc explains this. >>> >>> http://msdn2.microsoft.com/en-us/library/ms191504.aspx : >>> >>> "Null values generally indicate data that is unknown, not applicable, >>> or that the data will be added later." >> >> I really like that definition. It feels closest to what I think it should >> mean. >> >> -- >> Rory >> >> > >
<snip>
> My understanding is that the OP wasn't discussing the null C# keyword but I would largely agree, but soften the statement a little. It doesn't > the 2.0 "nullable types" feature > (http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to mark > a value type as being "null"? I would be very inclined to think that it were > precisely introduced to match the NULL marker found DBMS sidea nd that > wasn't available .NET side for value types until now. really "match" NULL in the database, but it's often used to represent a value which is NULL in a database (or which should be NULL after insertion/update). The rules for equality and logic are different to databases (and are also different in different languages, IIRC). A good example of this is the following program - it will produce output of "True", but a query trying to match using "=" in SQL wouldn't work: using System; class Program { static void Main(string[] args) { int? x = null; Console.WriteLine (x==null); } } -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > If you don't know the value, you don't know it is 27 so you'll have a NO! Stop right there. That is false! Just because I don't know the value > "null" value anyway as you can't do better.... doesn't mean it can't have a value (like 27). Variables are great examples of holders of potentially unknown values, that doesn't make all variables null does it? > Of course if you wanted to distinguish additional cases ("not know", "not Again, you are making my point! You just said that to distinguish these > applicable" etc...) you would have to keep an additional value acting as a > marker but I've never have to do this myself until then. other possibilities, you need some value acting as a marker, null is not sufficient for all these possibilities so how could your documentation be a good one for null. > My understanding is that the OP wasn't discussing the null C# keyword but I'm pretty sure I've said this a bunch of times at this point:> the 2.0 "nullable types" feature > (http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to > mark a value type as being "null"? I would be very inclined to think that > it were precisely introduced to match the NULL marker found DBMS sidea nd > that wasn't available .NET side for value types until now. > > Finally I would think he was expecting a bit more than a "formal > definition" (what is yours ?) null = no value > but sorry we are not allowed to tell you what this value could "indicate" You could, but that wouldn't be a definition of null (as the OP asked "what > in practice in your code... is actually a null value"). You have not provided a definition of null anywhere in your replies, just places where you *could* use null. Strange that you are asking me for something I've given, but not given yourself? Show quote > > I have nothing to add... > > -- > Patrice > > "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: > uH02rU6dHHA.3***@TK2MSFTNGP03.phx.gbl... >> But (again) that is SQL definition of what a null value *indicates*, not >> of what a the *definition* of null is. It is also limited to SQL, not >> the .NET Framework. >> >> This documentation essentially says "Use null as an indication of the >> following separate and different things...". That, in no way is a >> defition of what null represents. >> >> Wouldn't you agree that "an unknown value" could be a value of 27? Is 27 >> null? So, I would say that the documentation is actually poorly written >> (wouldn't be the first time). >> >> >> >> >> "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message >> news:b0ac48a083368c945bfa70ac670@msnews.microsoft.com... >>>> I will just end with how the SQL Server doc explains this. >>>> >>>> http://msdn2.microsoft.com/en-us/library/ms191504.aspx : >>>> >>>> "Null values generally indicate data that is unknown, not applicable, >>>> or that the data will be added later." >>> >>> I really like that definition. It feels closest to what I think it >>> should mean. >>> >>> -- >>> Rory >>> >>> >> >> > > >> If you don't know the value, you don't know it is 27 so you'll have Sorry Scott. I don't think you understand what Patrice is trying to say.>> a "null" value anyway as you can't do better.... >> > NO! Stop right there. That is false! Just because I don't know the > value doesn't mean it can't have a value (like 27). Variables are > great examples of holders of potentially unknown values, that doesn't > make all variables null does it? (In fairness, I can't guarentee that I do either but according to my interpretation, she's making sense. (erm that is a femanine name where you come from? Right Patrice? I don't want to be insulting anyone :) This thread's heated enough already. ) The way I see it, Patrice is trying to explain a valid use of null and therefore a meaning which is appropriate for it. When Patrice says "If you don't know the value, you don't know it is 27", she means.... If you don't tell the computer that you have 27 apples then this fact is unknown to the computer. This does not stop you from actually having the 27 apples though. As Patrice says, the best you can do is null (reasonably taken in this circumstance to mean 'unknown') You could decide to tell the computer that you have 27 apples or you could not. If you do not then the value would be null. (rather than 0 which most people would agrees represented the "solid fact of there being no apples at all) Therefore the null represents an as yet unknown or unspecified value. To put it another way. If the computer tells you "it has 'null' apples", what would any reasonable programmer taken that to mean. what would you take it to mean. Another good example could be a company with employees. you could (Please excuse the VB here but I'm quicker using it and there are only reference types in this example so initialising to null shouldn't be a contraversial point here) ------------------------------------------------------------- Class Company Private mCompanyName as String Public Employees as Collection(Of Employee) Public Sub New(CompanyName as String) mCompanyName = CompanyName End Sub End Class ------------------------------------------------------------- After construction, an object of type company, would be a (very incomplete) representation of a company in the real world. In the real world, the company might have 5 or 100 Emplyees. This information doesn't exist for the class yet and can it be reasonable stated that it is unknown to the class. However, we have not given an empty collection which might be interpreted as inticating the "solid fact" that the company has 0 employees. This is the use of null to mean that we do not know the correct value or that it is as yet not available to us(perhaps because a lazy load has not yet taken place or perhaps because the database record from which this data might have been drawn did not specify for this particular company. This is a common interpretation of the "meaning" null. As someone indicated earlier in this thread, the meaning of "meaning" is subject to interpretation (sorry for going a little bit meta). We can interpret as I have above or we can interpret as if the use wanted to know the strict definition of null. I feel that Patrice has the correct interpretation of the original poster's intention. The original posters question is best answered (IMHO) by indicating how one might usefully use a null. The truth is that nobody should care whether a variable was assigned null or whether it was null by virtue of not having ever been set. This is because after either of these 2 events has occurred, noone can tell which did cause it. At this point "unassigned" becomes the same as "assigned null" You can be as picky as you like and refer back to the specification as much as you like. Despite the fact that internally c#(and many other languages) represent null as a special yet constant value (so that (null = null) is true... .... Nobody cares what that value is (whether it is or is not a value). the real crux of the matter is "what is it used for?", "how is it useful?" or "what did the programmer of this code mean when (s)he used it?" Ok that was a lot to type and I think I've repeated myself a lot. I have not tried to insult anyone, so if you do feel as if I have then I'm sorry. Either way.... Tag.... you're all IT :P [BTW... "IT" is a special constant value (whose internal value we don't really care about) which when applied to an individual or group, designates them to be the person whose turn it is.] Sorry couln't resist :D -- Rory Rory,
I get what she is saying, but she is not getting my reply. As you state, she is giving *uses* for null, not a definition of null. This has been my whole point with her posts. I never said her example of the usage of null was wrong, I said it was wrong to hold the usage up as a definition, that's all. Show quote "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message news:b0ac48a0838e8c945e37bdb4550@msnews.microsoft.com... >>> If you don't know the value, you don't know it is 27 so you'll have >>> a "null" value anyway as you can't do better.... >>> >> NO! Stop right there. That is false! Just because I don't know the >> value doesn't mean it can't have a value (like 27). Variables are >> great examples of holders of potentially unknown values, that doesn't >> make all variables null does it? > > Sorry Scott. I don't think you understand what Patrice is trying to say. > > (In fairness, I can't guarentee that I do either but according to my > interpretation, she's making sense. (erm that is a femanine name where you > come from? Right Patrice? I don't want to be insulting anyone :) This > thread's heated enough already. ) > > The way I see it, Patrice is trying to explain a valid use of null and > therefore a meaning which is appropriate for it. > > When Patrice says "If you don't know the value, you don't know it is 27", > she means.... > > If you don't tell the computer that you have 27 apples then this fact is > unknown to the computer. This does not stop you from actually having the > 27 apples though. As Patrice says, the best you can do is null (reasonably > taken in this circumstance to mean 'unknown') > > You could decide to tell the computer that you have 27 apples or you could > not. > > If you do not then the value would be null. (rather than 0 which most > people would agrees represented the "solid fact of there being no apples > at all) > > Therefore the null represents an as yet unknown or unspecified value. > > To put it another way. If the computer tells you "it has 'null' apples", > what would any reasonable programmer taken that to mean. what would you > take it to mean. > > Another good example could be a company with employees. you could > (Please excuse the VB here but I'm quicker using it and there are only > reference types in this example so initialising to null shouldn't be a > contraversial point here) > > ------------------------------------------------------------- > Class Company > Private mCompanyName as String > Public Employees as Collection(Of Employee) Public Sub > New(CompanyName as String) > mCompanyName = CompanyName > End Sub End Class > ------------------------------------------------------------- > > After construction, an object of type company, would be a (very > incomplete) representation of a company in the real world. > In the real world, the company might have 5 or 100 Emplyees. > > This information doesn't exist for the class yet and can it be reasonable > stated that it is unknown to the class. > > However, we have not given an empty collection which might be interpreted > as inticating the "solid fact" that the company has 0 employees. > > This is the use of null to mean that we do not know the correct value or > that it is as yet not available to us(perhaps because a lazy load has not > yet taken place or perhaps because the database record from which this > data might have been drawn did not specify for this particular company. > > This is a common interpretation of the "meaning" null. > > As someone indicated earlier in this thread, the meaning of "meaning" is > subject to interpretation (sorry for going a little bit meta). > > We can interpret as I have above or we can interpret as if the use wanted > to know the strict definition of null. > > I feel that Patrice has the correct interpretation of the original > poster's intention. > > The original posters question is best answered (IMHO) by indicating how > one might usefully use a null. > > The truth is that nobody should care whether a variable was assigned null > or whether it was null by virtue of not having ever been set. > This is because after either of these 2 events has occurred, noone can > tell which did cause it. > > At this point "unassigned" becomes the same as "assigned null" > > You can be as picky as you like and refer back to the specification as > much as you like. > > Despite the fact that internally c#(and many other languages) represent > null as a special yet constant value (so that (null = null) is true... > ... Nobody cares what that value is (whether it is or is not a value). the > real crux of the matter is "what is it used for?", "how is it useful?" or > "what did the programmer of this code mean when (s)he used it?" > > Ok that was a lot to type and I think I've repeated myself a lot. I have > not tried to insult anyone, so if you do feel as if I have then I'm sorry. > > Either way.... Tag.... you're all IT :P > > [BTW... "IT" is a special constant value (whose internal value we don't > really care about) which when applied to an individual or group, > designates them to be the person whose turn it is.] > > Sorry couln't resist :D > > -- > Rory > > > Got it now but I give up anyway to understand what you thought that the OP
just wanted a definition without being interested in how he could use it... Bye. "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: ua$DSU8dHHA.4***@TK2MSFTNGP04.phx.gbl...Show quote > Rory, > > I get what she is saying, but she is not getting my reply. As you state, > she is giving *uses* for null, not a definition of null. This has been my > whole point with her posts. I never said her example of the usage of null > was wrong, I said it was wrong to hold the usage up as a definition, > that's all. > > > "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message > news:b0ac48a0838e8c945e37bdb4550@msnews.microsoft.com... >>>> If you don't know the value, you don't know it is 27 so you'll have >>>> a "null" value anyway as you can't do better.... >>>> >>> NO! Stop right there. That is false! Just because I don't know the >>> value doesn't mean it can't have a value (like 27). Variables are >>> great examples of holders of potentially unknown values, that doesn't >>> make all variables null does it? >> >> Sorry Scott. I don't think you understand what Patrice is trying to say. >> >> (In fairness, I can't guarentee that I do either but according to my >> interpretation, she's making sense. (erm that is a femanine name where >> you come from? Right Patrice? I don't want to be insulting anyone :) This >> thread's heated enough already. ) >> >> The way I see it, Patrice is trying to explain a valid use of null and >> therefore a meaning which is appropriate for it. >> >> When Patrice says "If you don't know the value, you don't know it is >> 27", she means.... >> >> If you don't tell the computer that you have 27 apples then this fact is >> unknown to the computer. This does not stop you from actually having the >> 27 apples though. As Patrice says, the best you can do is null >> (reasonably taken in this circumstance to mean 'unknown') >> >> You could decide to tell the computer that you have 27 apples or you >> could not. >> >> If you do not then the value would be null. (rather than 0 which most >> people would agrees represented the "solid fact of there being no apples >> at all) >> >> Therefore the null represents an as yet unknown or unspecified value. >> >> To put it another way. If the computer tells you "it has 'null' apples", >> what would any reasonable programmer taken that to mean. what would you >> take it to mean. >> >> Another good example could be a company with employees. you could >> (Please excuse the VB here but I'm quicker using it and there are only >> reference types in this example so initialising to null shouldn't be a >> contraversial point here) >> >> ------------------------------------------------------------- >> Class Company >> Private mCompanyName as String >> Public Employees as Collection(Of Employee) Public Sub >> New(CompanyName as String) >> mCompanyName = CompanyName >> End Sub End Class >> ------------------------------------------------------------- >> >> After construction, an object of type company, would be a (very >> incomplete) representation of a company in the real world. >> In the real world, the company might have 5 or 100 Emplyees. >> >> This information doesn't exist for the class yet and can it be reasonable >> stated that it is unknown to the class. >> >> However, we have not given an empty collection which might be interpreted >> as inticating the "solid fact" that the company has 0 employees. >> >> This is the use of null to mean that we do not know the correct value or >> that it is as yet not available to us(perhaps because a lazy load has not >> yet taken place or perhaps because the database record from which this >> data might have been drawn did not specify for this particular company. >> >> This is a common interpretation of the "meaning" null. >> >> As someone indicated earlier in this thread, the meaning of "meaning" is >> subject to interpretation (sorry for going a little bit meta). >> >> We can interpret as I have above or we can interpret as if the use wanted >> to know the strict definition of null. >> >> I feel that Patrice has the correct interpretation of the original >> poster's intention. >> >> The original posters question is best answered (IMHO) by indicating how >> one might usefully use a null. >> >> The truth is that nobody should care whether a variable was assigned null >> or whether it was null by virtue of not having ever been set. >> This is because after either of these 2 events has occurred, noone can >> tell which did cause it. >> >> At this point "unassigned" becomes the same as "assigned null" >> >> You can be as picky as you like and refer back to the specification as >> much as you like. >> >> Despite the fact that internally c#(and many other languages) represent >> null as a special yet constant value (so that (null = null) is true... >> ... Nobody cares what that value is (whether it is or is not a value). >> the real crux of the matter is "what is it used for?", "how is it >> useful?" or "what did the programmer of this code mean when (s)he used >> it?" >> >> Ok that was a lot to type and I think I've repeated myself a lot. I have >> not tried to insult anyone, so if you do feel as if I have then I'm >> sorry. >> >> Either way.... Tag.... you're all IT :P >> >> [BTW... "IT" is a special constant value (whose internal value we don't >> really care about) which when applied to an individual or group, >> designates them to be the person whose turn it is.] >> >> Sorry couln't resist :D >> >> -- >> Rory >> >> >> > > Because your first (and all the other) post(s) were only providing useage
scenarios. You never provided a definition. And (as I stated way back), the analogy you used, I feel was incorrect and misleading. Show quote "Patrice" <http://www.chez.com/scribe/> wrote in message news:O%23db3nEeHHA.1216@TK2MSFTNGP03.phx.gbl... > Got it now but I give up anyway to understand what you thought that the OP > just wanted a definition without being interested in how he could use > it... > > Bye. > > > "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: > ua$DSU8dHHA.4***@TK2MSFTNGP04.phx.gbl... >> Rory, >> >> I get what she is saying, but she is not getting my reply. As you state, >> she is giving *uses* for null, not a definition of null. This has been >> my whole point with her posts. I never said her example of the usage of >> null was wrong, I said it was wrong to hold the usage up as a definition, >> that's all. >> >> >> "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message >> news:b0ac48a0838e8c945e37bdb4550@msnews.microsoft.com... >>>>> If you don't know the value, you don't know it is 27 so you'll have >>>>> a "null" value anyway as you can't do better.... >>>>> >>>> NO! Stop right there. That is false! Just because I don't know the >>>> value doesn't mean it can't have a value (like 27). Variables are >>>> great examples of holders of potentially unknown values, that doesn't >>>> make all variables null does it? >>> >>> Sorry Scott. I don't think you understand what Patrice is trying to say. >>> >>> (In fairness, I can't guarentee that I do either but according to my >>> interpretation, she's making sense. (erm that is a femanine name where >>> you come from? Right Patrice? I don't want to be insulting anyone :) >>> This thread's heated enough already. ) >>> >>> The way I see it, Patrice is trying to explain a valid use of null and >>> therefore a meaning which is appropriate for it. >>> >>> When Patrice says "If you don't know the value, you don't know it is >>> 27", she means.... >>> >>> If you don't tell the computer that you have 27 apples then this fact is >>> unknown to the computer. This does not stop you from actually having the >>> 27 apples though. As Patrice says, the best you can do is null >>> (reasonably taken in this circumstance to mean 'unknown') >>> >>> You could decide to tell the computer that you have 27 apples or you >>> could not. >>> >>> If you do not then the value would be null. (rather than 0 which most >>> people would agrees represented the "solid fact of there being no apples >>> at all) >>> >>> Therefore the null represents an as yet unknown or unspecified value. >>> >>> To put it another way. If the computer tells you "it has 'null' apples", >>> what would any reasonable programmer taken that to mean. what would you >>> take it to mean. >>> >>> Another good example could be a company with employees. you could >>> (Please excuse the VB here but I'm quicker using it and there are only >>> reference types in this example so initialising to null shouldn't be a >>> contraversial point here) >>> >>> ------------------------------------------------------------- >>> Class Company >>> Private mCompanyName as String >>> Public Employees as Collection(Of Employee) Public Sub >>> New(CompanyName as String) >>> mCompanyName = CompanyName >>> End Sub End Class >>> ------------------------------------------------------------- >>> >>> After construction, an object of type company, would be a (very >>> incomplete) representation of a company in the real world. >>> In the real world, the company might have 5 or 100 Emplyees. >>> >>> This information doesn't exist for the class yet and can it be >>> reasonable stated that it is unknown to the class. >>> >>> However, we have not given an empty collection which might be >>> interpreted as inticating the "solid fact" that the company has 0 >>> employees. >>> >>> This is the use of null to mean that we do not know the correct value or >>> that it is as yet not available to us(perhaps because a lazy load has >>> not yet taken place or perhaps because the database record from which >>> this data might have been drawn did not specify for this particular >>> company. >>> >>> This is a common interpretation of the "meaning" null. >>> >>> As someone indicated earlier in this thread, the meaning of "meaning" is >>> subject to interpretation (sorry for going a little bit meta). >>> >>> We can interpret as I have above or we can interpret as if the use >>> wanted to know the strict definition of null. >>> >>> I feel that Patrice has the correct interpretation of the original >>> poster's intention. >>> >>> The original posters question is best answered (IMHO) by indicating how >>> one might usefully use a null. >>> >>> The truth is that nobody should care whether a variable was assigned >>> null or whether it was null by virtue of not having ever been set. >>> This is because after either of these 2 events has occurred, noone can >>> tell which did cause it. >>> >>> At this point "unassigned" becomes the same as "assigned null" >>> >>> You can be as picky as you like and refer back to the specification as >>> much as you like. >>> >>> Despite the fact that internally c#(and many other languages) represent >>> null as a special yet constant value (so that (null = null) is true... >>> ... Nobody cares what that value is (whether it is or is not a value). >>> the real crux of the matter is "what is it used for?", "how is it >>> useful?" or "what did the programmer of this code mean when (s)he used >>> it?" >>> >>> Ok that was a lot to type and I think I've repeated myself a lot. I have >>> not tried to insult anyone, so if you do feel as if I have then I'm >>> sorry. >>> >>> Either way.... Tag.... you're all IT :P >>> >>> [BTW... "IT" is a special constant value (whose internal value we don't >>> really care about) which when applied to an individual or group, >>> designates them to be the person whose turn it is.] >>> >>> Sorry couln't resist :D >>> >>> -- >>> Rory >>> >>> >>> >> >> > > ....And, only providing useage (context) is not always sufficient for a clear
understanding of meaning (definition). So, since you only provided useage, and I believe inaccurate useage at that (database useage of null [which was, in itself misleading], rather than .NET useage of null), there was no good description of C#'s null ever given by you. Show quote "Scott M." <s-mar@nospam.nospam> wrote in message news:OtdFclFeHHA.4172@TK2MSFTNGP05.phx.gbl... > Because your first (and all the other) post(s) were only providing useage > scenarios. You never provided a definition. And (as I stated way back), > the analogy you used, I feel was incorrect and misleading. > > > "Patrice" <http://www.chez.com/scribe/> wrote in message > news:O%23db3nEeHHA.1216@TK2MSFTNGP03.phx.gbl... >> Got it now but I give up anyway to understand what you thought that the >> OP just wanted a definition without being interested in how he could use >> it... >> >> Bye. >> >> >> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >> ua$DSU8dHHA.4***@TK2MSFTNGP04.phx.gbl... >>> Rory, >>> >>> I get what she is saying, but she is not getting my reply. As you >>> state, she is giving *uses* for null, not a definition of null. This >>> has been my whole point with her posts. I never said her example of the >>> usage of null was wrong, I said it was wrong to hold the usage up as a >>> definition, that's all. >>> >>> >>> "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message >>> news:b0ac48a0838e8c945e37bdb4550@msnews.microsoft.com... >>>>>> If you don't know the value, you don't know it is 27 so you'll have >>>>>> a "null" value anyway as you can't do better.... >>>>>> >>>>> NO! Stop right there. That is false! Just because I don't know the >>>>> value doesn't mean it can't have a value (like 27). Variables are >>>>> great examples of holders of potentially unknown values, that doesn't >>>>> make all variables null does it? >>>> >>>> Sorry Scott. I don't think you understand what Patrice is trying to >>>> say. >>>> >>>> (In fairness, I can't guarentee that I do either but according to my >>>> interpretation, she's making sense. (erm that is a femanine name where >>>> you come from? Right Patrice? I don't want to be insulting anyone :) >>>> This thread's heated enough already. ) >>>> >>>> The way I see it, Patrice is trying to explain a valid use of null and >>>> therefore a meaning which is appropriate for it. >>>> >>>> When Patrice says "If you don't know the value, you don't know it is >>>> 27", she means.... >>>> >>>> If you don't tell the computer that you have 27 apples then this fact >>>> is unknown to the computer. This does not stop you from actually having >>>> the 27 apples though. As Patrice says, the best you can do is null >>>> (reasonably taken in this circumstance to mean 'unknown') >>>> >>>> You could decide to tell the computer that you have 27 apples or you >>>> could not. >>>> >>>> If you do not then the value would be null. (rather than 0 which most >>>> people would agrees represented the "solid fact of there being no >>>> apples at all) >>>> >>>> Therefore the null represents an as yet unknown or unspecified value. >>>> >>>> To put it another way. If the computer tells you "it has 'null' >>>> apples", what would any reasonable programmer taken that to mean. what >>>> would you take it to mean. >>>> >>>> Another good example could be a company with employees. you could >>>> (Please excuse the VB here but I'm quicker using it and there are only >>>> reference types in this example so initialising to null shouldn't be a >>>> contraversial point here) >>>> >>>> ------------------------------------------------------------- >>>> Class Company >>>> Private mCompanyName as String >>>> Public Employees as Collection(Of Employee) Public Sub >>>> New(CompanyName as String) >>>> mCompanyName = CompanyName >>>> End Sub End Class >>>> ------------------------------------------------------------- >>>> >>>> After construction, an object of type company, would be a (very >>>> incomplete) representation of a company in the real world. >>>> In the real world, the company might have 5 or 100 Emplyees. >>>> >>>> This information doesn't exist for the class yet and can it be >>>> reasonable stated that it is unknown to the class. >>>> >>>> However, we have not given an empty collection which might be >>>> interpreted as inticating the "solid fact" that the company has 0 >>>> employees. >>>> >>>> This is the use of null to mean that we do not know the correct value >>>> or that it is as yet not available to us(perhaps because a lazy load >>>> has not yet taken place or perhaps because the database record from >>>> which this data might have been drawn did not specify for this >>>> particular company. >>>> >>>> This is a common interpretation of the "meaning" null. >>>> >>>> As someone indicated earlier in this thread, the meaning of "meaning" >>>> is subject to interpretation (sorry for going a little bit meta). >>>> >>>> We can interpret as I have above or we can interpret as if the use >>>> wanted to know the strict definition of null. >>>> >>>> I feel that Patrice has the correct interpretation of the original >>>> poster's intention. >>>> >>>> The original posters question is best answered (IMHO) by indicating how >>>> one might usefully use a null. >>>> >>>> The truth is that nobody should care whether a variable was assigned >>>> null or whether it was null by virtue of not having ever been set. >>>> This is because after either of these 2 events has occurred, noone can >>>> tell which did cause it. >>>> >>>> At this point "unassigned" becomes the same as "assigned null" >>>> >>>> You can be as picky as you like and refer back to the specification as >>>> much as you like. >>>> >>>> Despite the fact that internally c#(and many other languages) represent >>>> null as a special yet constant value (so that (null = null) is true... >>>> ... Nobody cares what that value is (whether it is or is not a value). >>>> the real crux of the matter is "what is it used for?", "how is it >>>> useful?" or "what did the programmer of this code mean when (s)he used >>>> it?" >>>> >>>> Ok that was a lot to type and I think I've repeated myself a lot. I >>>> have not tried to insult anyone, so if you do feel as if I have then >>>> I'm sorry. >>>> >>>> Either way.... Tag.... you're all IT :P >>>> >>>> [BTW... "IT" is a special constant value (whose internal value we don't >>>> really care about) which when applied to an individual or group, >>>> designates them to be the person whose turn it is.] >>>> >>>> Sorry couln't resist :D >>>> >>>> -- >>>> Rory >>>> >>>> >>>> >>> >>> >> >> > > Well no. This is actually the same as Patrick here in France. The feminim
form for us is Patricia. "Rory Becker" <RoryBecker@newsgroup.nospam> a écrit dans le message de news: b0ac48a0838e8c945e37bdb4***@msnews.microsoft.com...Show quote >>> If you don't know the value, you don't know it is 27 so you'll have >>> a "null" value anyway as you can't do better.... >>> >> NO! Stop right there. That is false! Just because I don't know the >> value doesn't mean it can't have a value (like 27). Variables are >> great examples of holders of potentially unknown values, that doesn't >> make all variables null does it? > > Sorry Scott. I don't think you understand what Patrice is trying to say. > > (In fairness, I can't guarentee that I do either but according to my > interpretation, she's making sense. (erm that is a femanine name where you > come from? Right Patrice? I don't want to be insulting anyone :) This > thread's heated enough already. ) > > The way I see it, Patrice is trying to explain a valid use of null and > therefore a meaning which is appropriate for it. > > When Patrice says "If you don't know the value, you don't know it is 27", > she means.... > > If you don't tell the computer that you have 27 apples then this fact is > unknown to the computer. This does not stop you from actually having the > 27 apples though. As Patrice says, the best you can do is null (reasonably > taken in this circumstance to mean 'unknown') > > You could decide to tell the computer that you have 27 apples or you could > not. > > If you do not then the value would be null. (rather than 0 which most > people would agrees represented the "solid fact of there being no apples > at all) > > Therefore the null represents an as yet unknown or unspecified value. > > To put it another way. If the computer tells you "it has 'null' apples", > what would any reasonable programmer taken that to mean. what would you > take it to mean. > > Another good example could be a company with employees. you could > (Please excuse the VB here but I'm quicker using it and there are only > reference types in this example so initialising to null shouldn't be a > contraversial point here) > > ------------------------------------------------------------- > Class Company > Private mCompanyName as String > Public Employees as Collection(Of Employee) Public Sub > New(CompanyName as String) > mCompanyName = CompanyName > End Sub End Class > ------------------------------------------------------------- > > After construction, an object of type company, would be a (very > incomplete) representation of a company in the real world. > In the real world, the company might have 5 or 100 Emplyees. > > This information doesn't exist for the class yet and can it be reasonable > stated that it is unknown to the class. > > However, we have not given an empty collection which might be interpreted > as inticating the "solid fact" that the company has 0 employees. > > This is the use of null to mean that we do not know the correct value or > that it is as yet not available to us(perhaps because a lazy load has not > yet taken place or perhaps because the database record from which this > data might have been drawn did not specify for this particular company. > > This is a common interpretation of the "meaning" null. > > As someone indicated earlier in this thread, the meaning of "meaning" is > subject to interpretation (sorry for going a little bit meta). > > We can interpret as I have above or we can interpret as if the use wanted > to know the strict definition of null. > > I feel that Patrice has the correct interpretation of the original > poster's intention. > > The original posters question is best answered (IMHO) by indicating how > one might usefully use a null. > > The truth is that nobody should care whether a variable was assigned null > or whether it was null by virtue of not having ever been set. > This is because after either of these 2 events has occurred, noone can > tell which did cause it. > > At this point "unassigned" becomes the same as "assigned null" > > You can be as picky as you like and refer back to the specification as > much as you like. > > Despite the fact that internally c#(and many other languages) represent > null as a special yet constant value (so that (null = null) is true... > ... Nobody cares what that value is (whether it is or is not a value). the > real crux of the matter is "what is it used for?", "how is it useful?" or > "what did the programmer of this code mean when (s)he used it?" > > Ok that was a lot to type and I think I've repeated myself a lot. I have > not tried to insult anyone, so if you do feel as if I have then I'm sorry. > > Either way.... Tag.... you're all IT :P > > [BTW... "IT" is a special constant value (whose internal value we don't > really care about) which when applied to an individual or group, > designates them to be the person whose turn it is.] > > Sorry couln't resist :D > > -- > Rory > > > "Patrice" <http://www.chez.com/scribe/> wrote in message What I don't like is exactly what I've been saying all along, we're not news:edMkW65dHHA.4032@TK2MSFTNGP02.phx.gbl... >I will just end with how the SQL Server doc explains this. > > http://msdn2.microsoft.com/en-us/library/ms191504.aspx : > "Null values generally indicate data that is unknown, not applicable, or > that the data will be added later." > > I'm not sure what is the point you don't like in this definition that > looks quite close to mine but it really looks like that understanding each > other on this topic is out of reach. talking about what a null value in SQL "INDICATES" (per your documentation). So your definition and link are irrelevant. We are talking about the DEFINITION of null in the .NET FRAMEWORK. What if another database's documentation had a different description of null? Would that change your understanding of what null means? > You too!> Take care and see you soon in another thread for another heated discussion > ;-) Show quote > > -- > Patrice > > "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: > OMPOZW5dHHA.4***@TK2MSFTNGP02.phx.gbl... >>I think you are making my point here. You introduced the concepts and >>terms: "unknown", "undefined" and "not applicable" into the disussion. In >>addition, you are talking about "why" a database needs the concept of a >>null (I personally think you mis-stated that, but that is besides the >>point). >> >> Below, you are talking about the practical use of null, rather than the >> meaning of null, which is the point of this thread. >> >> >> "Patrice" <http://www.chez.com/scribe/> wrote in message >> news:ecXux94dHHA.4032@TK2MSFTNGP02.phx.gbl... >>> I'm not using null when "I don't know what value the user may want to >>> input" (actually I never know what value the user will enter, not sure >>> what you meant). >>> >>> Also I don't use NULL when "I'm letting the user not put any value at >>> all into the field" which is IMO bad form at least to do systematically. >>> I'll use an empty string or 0 as a default value if it makes senses. >>> >>> I will use this for example for the actual start date of something that >>> not started yet. In this case you can't provide any value. IMO this is >>> a more convincing sample than Appartement number and the like where in a >>> real world scenario you never want to distinguish between a value that >>> can't be provided for some reason (null) and the fact that the apartment >>> number is just an empty string because you *know* this is an empty >>> string, not because you are unable to provide this value. >>> >>> This is perhaps why I tried at first to explain what's behind null. I >>> felt that using simply the word "null" was perhaps not sufficient as it >>> is IMO sometimes misused. >>> >>> --- >>> Patrice >>> >>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >>> OTi6AT4dHHA.1***@TK2MSFTNGP04.phx.gbl... >>>> Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," >>>> not applicable" have never been identified with "null" in SQL or >>>> anywhere else. When I mark a filed in SQL as "nullable", I am not doing >>>> it because I don't know what value the user may want to put into the >>>> field. On the contrary, I do it because I'm letting the user not put >>>> any value at all into the field. >>>> >>>> Again "undefined", "unknown"," not applicable" does not equal "null". >>>> I think this is super-important to be clear on, because "null" has a >>>> special purpose and meaning and the minute you try to attach a meaning >>>> that is something similiar, but not the same, to it, you confuse the >>>> issue and make it more complicated than it need be. >>>> >>>> >>>> "Patrice" <http://www.chez.com/scribe/> wrote in message >>>> news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl... >>>>> OK I perhaps see a bit better your semantic point. AFAIK some >>>>> additional "markers" were suggested in SQL standards to better define >>>>> various meanings of "undefined", "unknown"," not applicable" or >>>>> several other semantics given to NULL values but never made into >>>>> products... >>>>> >>>>> I perhaps miss also some nuances as English is not my native language >>>>> but hopefull the overall picture should be clear enough for the OP. >>>>> >>>>> >>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news: >>>>> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl... >>>>>> Something having an unknown value is not, in any way, related to a >>>>&g | |||||||||||||||||||||||
