DataGridViewComboBoxColumn и NullValue

Наверное, всем известна проблема сохранения пустого значения в полях со списком в случае выбора значения из справочника с сохранением в таблицу ИД значения, при этом возникает исключение, что нельзя присвоить Null переменной типа Integer.

Сам я данную проблему до сих пор решал введением в справочник записи с ИД=0 посредством использования для источника данных списка подобного представления:

create view v_list_MyDictionary
as
select 0 as [ID], '' as [name]
union
select [ID], [name] from MyDictionary

Способ рабочий, но ноль это ноль, а не Null, и может возникнуть ситуация, когда невозможно использовать целочисленное значение, даже отрицательное.

Сегодня опробовал способ, простой как валенок.
Изменил в DataTable тип соответствующего поля с Int32 на Object. При этом соответствующий параметр в UpdateCommand оставил DbType=Int32, ProviderType=Int. Всё работает просто замечательно, даже Ctrl+0. Проблем с вводом не должно быть, ибо пользователь выбирает только из имеющихся значений в списке и не может вставить нечисловое значение. Подозреваю что могут быть задержки с преобразованием типов на больших объемах данных, но это отдельная история.

Вопрос знатокам. Какие могут быть подводные камни при использовании типа Object в полях таблиц типизированных наборов данных?

Тыжных Иван,

Nullable типы (Int32?) почему бы не использовать?

Тыжных Иван,

автор
Проблем с вводом не должно быть, ибо пользователь выбирает только из имеющихся значений в списке и не может вставить нечисловое значение

осталось узнать, как эти пустые значения туда попадают?

автор
всем известна проблема сохранения пустого значения в полях со списком в случае выбора значения из справочника с сохранением в таблицу ИД значения, при этом возникает исключение, что нельзя присвоить Null переменной типа Integer.

известна всем, но можно и не вытаскивать их из базы, или они для Вас имеют какой то сакральный смысл?

Тыжных Иван

Наверное, всем известна проблема сохранения пустого значения в полях со списком в случае выбора значения из справочника с сохранением в таблицу ИД значения, при этом возникает исключение, что нельзя присвоить Null переменной типа Integer. Сам я данную проблему до сих пор решал введением в справочник записи с ИД=0 посредством использования для источника данных списка подобного представления: create view v_list_MyDictionary as select 0 as [ID], '' as [name] union select [ID], [name] from MyDictionary Способ рабочий, но ноль это ноль, а не Null, и может возникнуть ситуация, когда невозможно использовать целочисленное значение, даже отрицательное.

А просто добавить запись в таблицу "MyDictionary", которая бы соответствовала "пустому" (ака, "дефолтному") значению в целевой таблице?

Тыжных Иван

Сегодня опробовал способ, простой как валенок. Изменил в DataTable тип соответствующего поля с Int32 на Object. При этом соответствующий параметр в UpdateCommand оставил DbType=Int32, ProviderType=Int. Всё работает просто замечательно, даже Ctrl+0. Проблем с вводом не должно быть, ибо пользователь выбирает только из имеющихся значений в списке и не может вставить нечисловое значение. Подозреваю что могут быть задержки с преобразованием типов на больших объемах данных, но это отдельная история.

How to: Handle Null Values in a DataColumn

sphinx_mv
А просто добавить запись в таблицу "MyDictionary", которая бы соответствовала "пустому" (ака, "дефолтному") значению в целевой таблице?

Ну к примеру, есть справочник пользователей и таблица проектов. В проекте на разные работы можем назначить разных исполнителей, в т.ч. исполнитель может и не быть назначен. Вводить в справочник пользователя "Неназначен", не комильфо, ибо этот справочник и в других подсистемах используется.

sphinx_mv
How to: Handle Null Values in a DataColumn

При попытке присвоить этому свойству значение, отличное от ThrowException, для полей с типом Int приводит в появлению окошка с надписью "Недопустимое значение свойства". В статье почему-то про это умолчали.

Тыжных Иван
sphinx_mv How to: Handle Null Values in a DataColumn При попытке присвоить этому свойству значение, отличное от ThrowException, для полей с типом Int приводит в появлению окошка с надписью "Недопустимое значение свойства". В статье почему-то про это умолчали.

Вы внимательно прочитали последнюю строку из 4го пункта?

Set the property to any custom value valid for that column's data type.

Что "в переводе" означает "вбейте нужное значение в это поле".
В-общем, "я не знаю, что я делаю не так, но у меня все работает" (с)

sphinx_mv

Тыжных Иван пропущено... При попытке присвоить этому свойству значение, отличное от ThrowException, для полей с типом Int приводит в появлению окошка с надписью "Недопустимое значение свойства". В статье почему-то про это умолчали. Вы внимательно прочитали последнюю строку из 4го пункта? Set the property to any custom value valid for that column's data type. Что "в переводе" означает "вбейте нужное значение в это поле".

Там же выше написано в таблице (Nothing) - Returns null values as DBNull.

а (Nothing) поставить нельзя. Выходит исключение.

Тыжных Иван
sphinx_mv А просто добавить запись в таблицу "MyDictionary", которая бы соответствовала "пустому" (ака, "дефолтному") значению в целевой таблице? Ну к примеру, есть справочник пользователей и таблица проектов. В проекте на разные работы можем назначить разных исполнителей, в т.ч. исполнитель может и не быть назначен.

А на один проект быть много исполнителей быть может? :)

Тыжных Иван
Вводить в справочник пользователя "Неназначен", не комильфо, ибо этот справочник и в других подсистемах используется.

А лепить на каждый справочник вьюху с UNION значится "комильфо"? :)
В-общем, не особо убедительно... Скрыть от пользователя внутри любой системы "служебные" записи справочников с заведомо известными значениями идентификаторов никогда не было проблемой.

И про более чем вероятные неоднозначности при сопоставлении "пустого" значения отображаемому результату не стоит забывать... Разные разработчики, опечатки, большие/маленькие буквы, изменение смысловой нагрузки с течением времени и т.д. и т.п... И все - вместо того, чтобы просто взять значение описателя из справочной таблицы. И значение это будет одинаковым для любых выборок. И поменять его можно простым апдейтом одной-единственной записи вместо поиска во всех текстах запросов.

Еще момент... В некоторых СУБД NULL-значения в полях записей, входящих в индексы при определенных условиях не индексируются. Соотвественно, получить "не комильфо" при выборках с фильтрами по таким полям более чем актуально.