数据绑定和数据源出现问题.

数据绑定和数据源出现问题.

问题描述:

你好,
我目前正在尝试数据绑定.
现在有一个我似乎无法解决的问题.

我有一个带有数据表的数据集.在此数据表中,我有一个不允许使用空值的列.
现在,我有一个BindingSource,它的数据集为DataSource,而DataTable为其数据成员,而BindingNavigator为BindingSource,其为BindingSource属性.一切顺利,直到我将非null列留空并尝试导航到DataTable中的另一行或添加新行.它使应用程序完全崩溃...如果我仅调用DataSource.EndEdit方法,则只会得到NoNullAllowedException.

我的DataTable的字段显示在TextBoxes中,而不是DataGrids中.

我已经检查了所有DataSource事件,属性,子和函数,但是找不到任何方法可以让我在更新/添加新行/导航到另一行或调用DataSource.EndEdit方法之前检查所有值是否都正确.

关于克服这个问题有什么建议吗?谢谢.

Hello,
I am currently experimenting with databinding.
Now there is one problem I cannot seem to fix.

I have a DataSet with a DataTable. In this DataTable I have a Column which does not allow null values.
Now I have a BindingSource which has the DataSet as its DataSource and the DataTable as its DataMember and a BindingNavigator which has the BindingSource as its BindingSource property. All goes well until I leave the non-null column empty and try to navigate to another row in the DataTable or add a new row. It makes the application crash altogether... If I just call the DataSource.EndEdit method I only get a NoNullAllowedException.

The fields of my DataTable are shown in TextBoxes, not DataGrids.

I have checked all the DataSource events, properties, subs and functions, but I cannot find any method that allows me to check if all values are OK before I update/add new row/ navigate to another row or call the DataSource.EndEdit method.

Any suggestions on overcoming this? Thanks.

在您应用于问题的所有标记中,您忘记包括一个用于数据库类型的标记(SQL Server,Access,MySQL,????). ).

仍然有一个建议.如果您的数据库允许将列的默认值设置为0或您的方案的任何明智的数字可能会解决此问题.如果不是,则将那个TextBox初始化为0(或任何其他值)可能会达到相同的结果.

如果这些建议都不适合或作为替代建议,请考虑处理验证 [ ^ ]事件.
Amongst all the tags you applied to your question you forgot to include one for the type of Database (SQL Server, Access, MySQL, ????).

Still, one suggestion. If your database allows default values for columns setting that to 0 or any sensible number for your scenario might resolve the problem. If not, then having that TextBox initialized to a value of 0 (or whatever) might achieve the same result.

If neither of those suggestions suit, or as an alternative, consider handling the Validating[^] event.