如何在 XSD 数据集中处理 DBNull 到布尔值的转换？
在我的数据库中，我的一个表中有几列是位（布尔）值。 它们允许为 NULL，因为字段并不总是包含数据。
我已经完成了使用该表创建 XSD 数据集的过程，并确保AllowDBNull 字段设置为True。
但是，当我使用配置的 GetData 方法将数据库中的记录拉入数据表时，遇到以下错误：
[InvalidCastException: Conversion from type 'DBNull' to type 'Boolean' is not valid.]
我是否需要在列的 DefaultValue 字段中指定其他内容，或者是否有其他字段需要指定放？
我这个项目仍处于开发阶段，因此，如果首选将字段更改为 char 并使用 Y/N/NULL 选项，那么我不太反对这样做。
In my database, I have a few columns in one of my tables that are bit (boolean) values. They are allowed to be NULL since the fields are not always going to contain data.
I've gone through the process of creating an XSD DataSet using the table and made sure that the AllowDBNull field is set to True.
However, when I pull a down record from the database into the datatable using the configured GetData method, I run into the following error:
[InvalidCastException: Conversion from type 'DBNull' to type 'Boolean' is not valid.]
Do I need to specify something other than in the DefaultValue field for the column, or is there some other field to set?
I am in the development phase still with this project, so if changing the fields to a char and using a Y/N/NULL option is preferred, I'm not too adverse to going that way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我必须不同意伊恩的观点。 三值逻辑与二值逻辑一样可行。 表中的人是活着还是死了，或者你不知道他是活着还是死了。 如果迈克有他的办法，你就不能在这里使用一点。 您需要一个状态表的 FK，1= 活着，2= 死亡，3= 未知。
该位的全部目的是节省空间，您始终可以将该列设置为 CHAR(1)，并使用约束将值限制为 T 或 F、Y 或 N（或 U）。
但我认为伊恩误解了迈克的话。 Mike 并不阻止使用 Null，毕竟他认为 EndDate 列应该为 null，直到该过程完成。 他只是说不要在列中注入具有神秘属性的空值......就像它是了解进程是否处于某种状态的关键一样。
事实上，数据库中的空值具有某些非常有用的副作用。 Oracle（也许其他数据库）不索引空值。 因此，如果您有一个列，其中只有一个值很重要 - 例如，您有一个从未清除的员工列表和一个已编制索引的 Is_Active_Employee 位列。 在这种情况下，对于一家已建立的企业，您拥有的员工人数是 >>> 比你现在拥有的员工数量。 假设你有 1% 的 1 和 99% 的 0。
该索引比实际需要的大 99 倍。 它对所有 1 进行索引，这很好，因为它们占表的 1%，但它也为您永远无法使用该索引查找的行加载了 0。 如果您想要所有不活跃的员工，则索引将被忽略并执行 FTS。 因此，从数据库的角度来看，1 和 NULL 会更有效。
I have to disagree with Iain. Three value logic is just as viable as 2 value logic. The person in the table is alive or dead or you don't know if he's alive or dead. If mike had his way, you couldn't use a bit here. You'd need an FK to a table of status, 1= Alive, 2=Dead, 3=Unknown.
The whole purpose of the bit is to save space, you could always make the column a CHAR(1) with a Constraint limiting the values to T or F, Y or N (or U).
But I think Iain is misinterpreting what Mike is saying. Mike's not discouraging the use of Nulls, after all he thinks the EndDate column should be null until the process is done. He's just saying don't imbue a null value in the column with mystic properties... like it's the key for knowing if a process is in a certain state.
In fact, Nulls in a database have certain very useful side-effects. Oracle (maybe other databases) doesn't index nulls. SO if you have a column where only one value is important -- like say you have an employee list you never purge and an Is_Active_Employee Bit Column that's indexed. In this case, for an established business, the number of employees you've had is >>> than the number of employees you have now. Say you have 1% 1's and 99% 0's.
That index is 99x larger than it needs to be. It's indexing all the 1's which is fine since they are 1% of the table but it's also loaded with 0's for rows you COULD NEVER use that index to find. If you want's all the inactive employees, the indexed would be ignored and a FTS would be performed. So 1 and NULL would be MUCH more efficient from a database perspective.
恕我直言，您不应该允许位/布尔字段中存在空值。
Mike Hadlow 在此处发表了一篇很好的文章：
http://mikehadlow.blogspot。 com/2006/10/nullability-voodoo.html
根据定义，布尔值是双态类型。 通过使其可为空，您将添加第三种状态。 它会在某个时候回来困扰你。
IMHO you shouldn't allow nulls in a bit/boolean field.
Mike Hadlow has a good post on this here:
http://mikehadlow.blogspot.com/2006/10/nullability-voodoo.html
Boolean is by definition a bi-state type. By making it nullable, you are adding a third state. It will come back to haunt you at some point.