Показать сообщение отдельно
Старый 17.02.2014, 12:56   #17  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Точно, я неверно сформулировал исходную проблему: поля создались изначально при синхронизации в рамках контрольного списка установки со значением по умолчанию null, но когда создавались записи компаний, конфигурационный ключ LedgerAdvConsolidations уже был выключен, поэтому поля, связанные с консолидацией, не были заполнены значением по умолчанию для соответствующего базового типа (enum) и так и остались null. Проблем обнаружилось три:
  • включение конфигурационного ключа не привело к заполнению связанных с ним полей в существующих записях значением по умолчанию для их базового типа в приложении
  • ядро ожидает, что всегда получит значение поля, отличное от null, если оно явно указало поле в списке выборки select
  • стандартный код, без проверки состояния конфигурационного ключа обращающийся к полям, привязанным к этому ключу, до включения ключа закономерно валился с ошибкой, потому что ядро даже не пыталось выбрать значения полей из базы, а после включения ключа валился с ошибкой, потому что ядро явно пыталось выбрать значения, но получало null и считало, что значения полей явно не были выбраны.
По сути, ошибка «Поле "%1" в таблице "%2" не было явным образом выбрано» в данном случае вводит в заблуждение, потому что путает понятия явного указания поля в select и получения null в качестве значения этого поля. Последнее может быть как следствием того, что поле не выбиралось, так и следствием того, что оно выбиралось, но в БД оно имеет значение null.

Последний раз редактировалось gl00mie; 17.02.2014 в 13:05. Причина: дополнение
За это сообщение автора поблагодарили: sukhanchik (4).