Цитата:
Сообщение от
oip
Сергей, а приведи какой-нибудь более-менее реальный пример, когда отличие в айдишниках хоть как-то повлияет на функционал и работоспособность системы? Мне в голову приходят только совсем уж клинические вещи.
1. Добавление складской аналитики.
В девелоперской базе проводили тестовые добавления, в результате финальный вариант складской аналитики один FieldID. Аналитику настраивают, проверяют. Все работает.
Затем проект переносят (без сохранения ID) в рабочую базу. FieldID у новой складской аналитики другой. Но этого не замечают и Без тени сомнения переносят настройки. Настройка складской аналитики основана на том, что в базе хранятся FieldID, поэтому все настройки сьезжают и не работают.
===================
2. Изменение складской аналитики
В девелоперской добавили складскую аналитику и руками добавили складскую аналитику в рабочую (FieldID разные). В рабочей настроили, работают. InventDim заполняется значениями для новой аналитики.
Потом какой-нибудь "негодяй" решает перенести InventDim проектом (с сохранением ID). При синхронизации поле со старым ID удаляется и создается поле с таким же именем, но другим ID. Естественно только что созданное поле будет пустым. InventDim будет невалидным.
====================
3. Полный список проблемных мест (с точки зрения ID) в стандартном функционале ax4.0 (всего потенциально опасных 1122 места, из них 139 в таблицах)
См. таблицу в аттаче.
Технология обнаружения проблемных мест в любой базе:
берете системные типы FieldID и TableID, смотрите по перекрестным ссылкам где они используются. Оставляете только те записи тип которых = Write. Убираете методы \modifiedField, \validateField, \Unpack, \Lookup