没有默认值属性设置的是/否类型的A97表字段是否具有默认值？ [英] A97 table field of Yes/No type without a default value property setting has a default value?
问题描述
我有一个带有Yes / No字段的A97表名为
TowJob和绑定到该表的表单。
表单上的TowJob控件绑定到相同的
字段。这是一个选项组，其中包含Yes和No bttns
分别为-1和0。
除非我专门设置表字段'的defaultvalue
到Null，窗体中出现一个自动值
控制中的
为0？该控件没有默认值
值属性设置。为什么会这样？
为什么必须将一个表格字段的'
defaultvalue属性设置为Null而不是简单地输入
什么都没有进入defaultvalue属性设置字段？
MLH写道：
为什么必须显式设置一个表字段的
defaultvalue属性为Null，而不是简单地在defaultvalue属性设置字段中输入
什么都没有？
我不确定，但这就是在Access中Yes / No字段类型的工作方式。
在相关主题上，听起来好像你可能依赖于Null为
值，因此您有一个Yes / No字段的值。通常认为做这种事情并不是一个好主意。事实上，
严格的数据库设计理论家会告诉你记录中没有字段
应该是null（关于这个概念和实际做法的想法是什么） $ b当然不同）。 Nulls不包含在索引中，null不会
等于null。
我这种方法的方法是使用数字字段和限制
值为0,1,2或1,2,3或其他什么。你可能会发现这是一个更好的方法来做事情并限制使用是/否字段到dtabase
只有两种状态的实体。
-
Tim http：/ /www.ucs.mun.ca/~tmarshal/
^ o<
/＃）" Burp-beep，burp-beep，burp-哔"？; - Quaker Jake
/ ^^Whatcha doin？ - 同上TIM-MAY !! - 我
我明白你的意思了。我只是看到它有点不同。我相信
null值有用。没有数据
在一张不存在的记录中是可以的，对吧。记录不会被写入b
，直到我的儿子毕业，是一个完美的例子，这是一个不存在的记录。无论是在一个高额的b
学校文件柜中保存在纸上还是记录在一个数据库中，我们都可以谈论它。我们可以称之为一个尚未写入的记录
如果我们想要。那有点
详细。可以使用像Null这样的单词来表示这样的记录。同样，Suzie秘书
还没有完全完成的记录中的字段也可以这样。只需
给Suzie更多时间，他们就会完整。
同时，我们可以谈谈
aren领域的价值观还没到？我们当然可以。我们必须始终将
称为不存在的价值吗？我不认为这是b $ b。我们可以同意使用Null这个词来表示
指的是尚未存在的值。如果我在这样的字段中要求您获得
的价值，我会接受来自
的回复，我会知道你的意思。就个人而言，我更喜欢
Null作为答案。我不喜欢把
a空间，或dbl-quotes或其他任何东西用来代表
什么都不做什么当NOTHING本身做得相当不错时这是
吧。如果尚未使用值
完成是/否字段，那么说这就完全合情合理。没有什么可以让我知道什么时候把东西放在那里什么东西
完成工作 - 就好了。 Nulls对我来说很有意义。
A Yes / No字段名为[HaveTheHorsesBeenFed]可以包含
Null如果什么马？是你得到的答案，或者可能是肯定的
或不，取决于稳定男孩的说法。
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2005年6月15日星期三11:26:25 -0230，Tim Marshall
< TI **** @ PurplePandaChasers.Moertherium>写道：
MLH写道：
为什么必须将一个表格字段的'defaultvalue属性设置为Null而不是只是在defaultvalue属性设置字段中输入
什么都没有？
我不确定，但这就是Yes / No字段类型的工作方式访问。
在相关主题上，听起来好像你可能依赖Null作为
值，因此你有一个Yes / No字段的值。通常认为做这种事情并不是一个好主意。事实上，严格的数据库设计理论家会告诉你，记录中的任何字段都不应该为空（当然，对这个概念和实际实践的想法不同）。 Nulls不包含在索引中，null不等于null。
我这种方法的方法是使用数字字段并将值限制为0 ，1,2或1,2,3或其他什么。你可能会发现这是一个更好的方法来做事情并限制使用是/否字段到dtabase
只有两种状态的实体。
" MLH" < CR ** @ NorthState.net>在留言中写道
news：4i ******************************** @ 4ax.com ...我明白你的意思了。我只是看到它有点不同。我相信
空值有用。没有数据可以存在于不存在的记录中，对吧。在我的儿子毕业之前，一份不会被写的记录说是一个完美的例子，这是一个不存在的记录。无论是在高档学校文件柜中保存在纸上还是记录在数据库中，我们都可以谈论它。我们可以称之为尚未写入的记录。如果我们想要。那有点啰嗦。可以使用像Null这样的词来指代这样的记录。同样，Suzie秘书尚未完全完成的记录中的字段也可以这样。只要给Suzie一些时间，他们就会完整。
同时，我们能谈谈那些还没有的领域的价值观吗？我们当然可以。我们必须始终将
称为尚未存在的价值吗？我不这么认为。我们可以同意使用Null这个词来指代尚未存在的值。如果我问你在这样一个领域的价值，我会接受你的回复，我会知道你的意思。就个人而言，我更喜欢Null作为答案。我并不是真的喜欢把空间，或dbl-quotes或其他任何东西用来代表
什么时候什么都没有，因为它本身并不是很好。
它。如果尚未使用值
完成是/否字段，那么说出这一点对我来说是完全合理的。当NOthing
完成工作时，将某些东西放在那里对我来说没有意义 - 就好了。空虚对我有意义。
这并不是那么简单。
你所描述的空记录对我来说毫无意义。表中没有一行
行表中没有一行。那不是什么都没有，
只是一个不存在的东西。并且所有适当的尊重看起来像是试图通过与不存在
的记录进行似是而非的比较来证明这些空白_字段。
具有空值的记录中的字段是不同的。它们被怀疑地处理的原因是实际意义不明确。
null表示该字段不存在任何值，或者值是
未知？
一个名为[HaveTheHorsesBeenFed]的是/否字段可以包含
Null如果什么马？是你得到的答案，或者可能是是
或否，取决于稳定的男孩所说的。
当然。但是数据库不应该提供答案而不是提问吗？
Fabian Pascal数据库管理中的实际问题（Addison Wesley，
ISBN 0- 201-48555-9）有一个很好的章节（第10章）。
Null是关系数据库理论中的一个问题。这个事实没有回合
。什么是2值逻辑现在成为4值逻辑 -
是/否/缺失/未知。
我的数据库中是否允许空字段？是。那个
一直是最好的设计选择吗？不可以。替代方案，很多时候
是将表的可空部分拆分成单独的表。但是这个结果使得结构变得更加复杂，有时甚至更多。在一个不错的
DBMS这样的Access中，它的绑定形式等等，这可以使得b $ b开发变得更加困难。
此时，有人会开始关于''关系数据库'
理论家'以及所有这些。据说，访问是一种关系数据库工具。
我们忽略了这个理论，这是我们的危险所在。我从来没有读过任何完全没有意义的理论家。许多人类活动都有b $ b理论基础。并不代表我们总能实施这一理论。但是很难理解这个理论，特别是Pascal和CJ所阐述的日期
一次又一次地提醒我们，数据库应该是_meaning_。
它是一阶谓词逻辑的基础迫使我们思考
数据实际意味着什么。
那么你的null是什么布尔值HaveTheHorsesBeenFed字段中的值
表示。他们还没有吃饱？马，什么马？我们没有马匹吗？
稳定的男孩们已经从马厩里回来并且正在做一件工作以便这样做
不会告诉我们他们是不是有没有吃过饭？当我很好的时候他们会被喂食
并准备好了吗？
Mike
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
< 2005年6月15日星期三11:26:25 -0230，Tim Marshall
< TI **** @ PurplePandaChasers.Moertherium>写道：
MLH写道：
为什么必须将一个表格字段的'defaultvalue属性设置为Null而不是只是在defaultvalue属性设置字段中输入
什么都没有？
我不确定，但这就是Yes / No字段类型的工作方式访问。
在相关主题上，听起来好像你可能依赖Null作为
值，因此你有一个Yes / No字段的值。通常认为做这种事情并不是一个好主意。事实上，严格的数据库设计理论家会告诉你，记录中的任何字段都不应该为空（当然，对这个概念和实际实践的想法不同）。 Nulls不包含在索引中，null不等于null。
我这种方法的方法是使用数字字段并将值限制为0 ，1,2或1,2,3或其他什么。你可能会发现这是一个更好的方法来做事情并限制使用是/否字段到dtabase
只有两种状态的实体。
I have an A97 table with a Yes/No field named
TowJob and a form bound to that table. The
TowJob control on the form is bound to the same
field. It is an option group with Yes and No bttns
valued at -1 and 0 respectively.
Unless I specifically set the table field''s defaultvalue
to Null, the form comes up with an automatic value
of 0 in the control? The control has NO default
value property setting. Why is that?
Why must one EXPLICITYLY set a table field''s
defaultvalue property to Null instead of simply entering
nothing at all into the defaultvalue property setting field?
MLH wrote:
Why must one EXPLICITYLY set a table field''s
defaultvalue property to Null instead of simply entering
nothing at all into the defaultvalue property setting field?
I''m not sure, but that''s the way the Yes/No field type works in Access.
On a related subject, it sounds as if you might be relying on Null as a
value so that you''d have three values for a Yes/No field. It''s
generally considered not a good idea to do this sort of thing. In fact,
strict database design theorists will tell you no field in a record
should ever be null (thoughts on this concept and actual practice do
differ, of course). Nulls aren''t included in indexes and null does not
equal null.
My approach to this sort of thing is to use a numeric field and limit
the values to 0, 1, 2 or 1, 2, 3 or something. You might find this a
better way to do things and restrict the use of Yes/No fields to dtabase
entities for which there are only two states.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
I see your point. I just see it a bit differently perhaps. I believe
null values serve a useful purpose. It is OK to have no data
in a record that doesn''t exist, right. A record that won''t be
written say, until my son graduates, is a perfect example of
a record that doesn''t exist. Whether its a record in a high
school filing cabinet maintained on paper or a record in
a database, we can talk about it. We can call it "a record
that hasn''t been written yet" if we want. That''s somewhat
verbose. Its OK to use a word like Null to refer to such
a record. Likewise, fields in a record that Suzie Secretary
hasn''t fully completed yet are OK to be that way. Just
give Suzie some more time and they''ll be complete.
Meanwhile, can we talk about values in the fields that
aren''t there yet? Sure we can. Must we always refer
to them though as "values that aren''t there yet"? I
don''t think so. We can agree to use the word Null to
refer to values that aren''t there yet. If I ask you for a
value in such a field, I''ll accept either response from
you and I''ll know what you mean. Personally, I prefer
Null as the answer. I don''t really like the idea of putting
a space, or dbl-quotes, or anything else at all to represent
nothing when NOTHING itself does quite a good job of
it. If a Yes/No field hasn''t been completed with a value
yet, it makes perfect sense to me to say just that. It doesn''t
make sense to me to put SOMEthing in there when NOthing
does the job - just fine. Nulls make sense to me.
A Yes/No field named [HaveTheHorsesBeenFed] could contain
Null if "What horses?" is the answer you get, or it could be Yes
or No, depending on what the stable boy says.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Wed, 15 Jun 2005 11:26:25 -0230, Tim Marshall
<TI****@PurplePandaChasers.Moertherium> wrote:
MLH wrote:Why must one EXPLICITYLY set a table field''s
defaultvalue property to Null instead of simply entering
nothing at all into the defaultvalue property setting field?
I''m not sure, but that''s the way the Yes/No field type works in Access.
On a related subject, it sounds as if you might be relying on Null as a
value so that you''d have three values for a Yes/No field. It''s
generally considered not a good idea to do this sort of thing. In fact,
strict database design theorists will tell you no field in a record
should ever be null (thoughts on this concept and actual practice do
differ, of course). Nulls aren''t included in indexes and null does not
equal null.
My approach to this sort of thing is to use a numeric field and limit
the values to 0, 1, 2 or 1, 2, 3 or something. You might find this a
better way to do things and restrict the use of Yes/No fields to dtabase
entities for which there are only two states.
"MLH" <CR**@NorthState.net> wrote in message
news:4i********************************@4ax.com...I see your point. I just see it a bit differently perhaps. I believe
null values serve a useful purpose. It is OK to have no data
in a record that doesn''t exist, right. A record that won''t be
written say, until my son graduates, is a perfect example of
a record that doesn''t exist. Whether its a record in a high
school filing cabinet maintained on paper or a record in
a database, we can talk about it. We can call it "a record
that hasn''t been written yet" if we want. That''s somewhat
verbose. Its OK to use a word like Null to refer to such
a record. Likewise, fields in a record that Suzie Secretary
hasn''t fully completed yet are OK to be that way. Just
give Suzie some more time and they''ll be complete.
Meanwhile, can we talk about values in the fields that
aren''t there yet? Sure we can. Must we always refer
to them though as "values that aren''t there yet"? I
don''t think so. We can agree to use the word Null to
refer to values that aren''t there yet. If I ask you for a
value in such a field, I''ll accept either response from
you and I''ll know what you mean. Personally, I prefer
Null as the answer. I don''t really like the idea of putting
a space, or dbl-quotes, or anything else at all to represent
nothing when NOTHING itself does quite a good job of
it. If a Yes/No field hasn''t been completed with a value
yet, it makes perfect sense to me to say just that. It doesn''t
make sense to me to put SOMEthing in there when NOthing
does the job - just fine. Nulls make sense to me.
It''s not as simple as that.
A ''null record'' as you describe it looks meaningless to me. It there isn''t a
row in a table there isn''t a row in a table. That''s not a null anything,
just a non-existant thing. And with all due respect looks like an attempt to
''justify'' null _fields_ with a specious comparison to records that don''t
exist.
A field in a record with a null value is different. The reason that they are
treated suspiciously is that the actual meaning is ambiguous.
Does null mean that no value can exist for that field, or that the value is
unknown?
A Yes/No field named [HaveTheHorsesBeenFed] could contain
Null if "What horses?" is the answer you get, or it could be Yes
or No, depending on what the stable boy says.
Sure. But shouldn''t the database be supplying answers, not asking questions?
Practial Issues in Database Management by Fabian Pascal (Addison Wesley,
ISBN 0-201-48555-9) has a good chapter on this (chapter 10).
Nulls are a problem in relational database theory. There''s no getting round
that fact. What was 2 valued logic now becomes 4 valued logic -
yes/no/missing/unknown.
Do I have fields which are allowed null in my databases? Yes. Has that
always been the best design choice? No. The alternative, a lot of the time
is to spin off the nullable part of tables into seperate tables. But this
makes the structure more, and sometimes a lot more, complex. And in a nice
DBMS like Access, with it''s bound forms and suchlike, this can make
development substantially harder.
At this point somebody''s going to start on about ''relational database
theorists'' and all that. Access is, supposedly, a relational database tool.
We ignore the theory at our peril. I have never read anything by the
''theorists'' that hasn''t made complete sense. Many human activities have a
''theoretical'' basis. Doesn''t mean we can always implement the theory. But
looking hard at the theory, especially as expounded by Pascal and CJ Date
reminds us, again and again that the database should be about _meaning_.
That it''s foundation in first order predicate logic forces us to think about
what the data actually mean.
So what does your null value in your boolean HaveTheHorsesBeenFed field
mean. They haven''t been fed? Horses, what horses? We don''t have any horses?
The stable boys have come back from the stables and are on a work to rule so
won''t tell us whether they''ve been fed or not? They''ll get fed when I''m good
and ready?
Mike
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Wed, 15 Jun 2005 11:26:25 -0230, Tim Marshall
<TI****@PurplePandaChasers.Moertherium> wrote:MLH wrote:Why must one EXPLICITYLY set a table field''s
defaultvalue property to Null instead of simply entering
nothing at all into the defaultvalue property setting field?
I''m not sure, but that''s the way the Yes/No field type works in Access.
On a related subject, it sounds as if you might be relying on Null as a
value so that you''d have three values for a Yes/No field. It''s
generally considered not a good idea to do this sort of thing. In fact,
strict database design theorists will tell you no field in a record
should ever be null (thoughts on this concept and actual practice do
differ, of course). Nulls aren''t included in indexes and null does not
equal null.
My approach to this sort of thing is to use a numeric field and limit
the values to 0, 1, 2 or 1, 2, 3 or something. You might find this a
better way to do things and restrict the use of Yes/No fields to dtabase
entities for which there are only two states.
这篇关于没有默认值属性设置的是/否类型的A97表字段是否具有默认值？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
