Точно, я неверно сформулировал исходную проблему: поля создались изначально при синхронизации в рамках контрольного списка установки со значением по умолчанию null, но когда создавались записи компаний, конфигурационный ключ LedgerAdvConsolidations уже был выключен, поэтому поля, связанные с консолидацией, не были заполнены значением по умолчанию для соответствующего базового типа (enum) и так и остались null. Проблем обнаружилось три:
- включение конфигурационного ключа не привело к заполнению связанных с ним полей в существующих записях значением по умолчанию для их базового типа в приложении
- ядро ожидает, что всегда получит значение поля, отличное от null, если оно явно указало поле в списке выборки select
- стандартный код, без проверки состояния конфигурационного ключа обращающийся к полям, привязанным к этому ключу, до включения ключа закономерно валился с ошибкой, потому что ядро даже не пыталось выбрать значения полей из базы, а после включения ключа валился с ошибкой, потому что ядро явно пыталось выбрать значения, но получало null и считало, что значения полей явно не были выбраны.
По сути, ошибка «Поле "%1" в таблице "%2" не было явным образом выбрано» в данном случае вводит в заблуждение, потому что путает понятия явного указания поля в select и получения null в качестве значения этого поля. Последнее может быть как следствием того, что поле не выбиралось, так и следствием того, что оно выбиралось, но в БД оно имеет значение null.