Различие Id объектов в Приложении разработки и рабочем

[mazzy]

Цитата:

Сообщение от 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

[mazzy]

См. также рекомендации здесь
palleagermark: Dealing with changed table or field id's

[oip]

Цитата:

Сообщение от mazzy

и Без тени сомнения переносят настройки. Настройка складской аналитики основана на том, что в базе хранятся FieldID, поэтому все настройки сьезжают и не работают.

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

Цитата:

Сообщение от mazzy

Потом какой-нибудь "негодяй" решает перенести InventDim проектом (с сохранением ID)

Опять-таки, это понятно и выше написано, что если айдишники разные, то с сохранением айдишников переносить проекты нельзя. Глеб это написал в первом же сообщении.

Эти все примеры не о "правильности" программирования говорят, а о правильности процедуры настройки приложения (в первом случае) и правильности процедуры его обновления (во втором).

[mazzy]

Цитата:

Сообщение от oip

Эти все примеры не о "правильности" программирования говорят, а о правильности процедуры настройки приложения (в первом случае) и правильности процедуры его обновления (во втором).

А неправильность программирования проявляется:
1. в наличии констант-идентификаторов в коде.
2. в предположении, что идентификаторы никогда не изменяются (даже системные)
3. в наличии вызовов объектов по идентификатору объекта (сколько раз видел)
4. в наличии создания объектов по идентификатору объекта (сколько раз видел)
5. в неграмотном юзании Dict-классов
6. в неправильной обработке ошибок в паттерне pack/unpack
7. в очень неграмотном юзании кэша (в него зачастую записывают идентификаторы)
8. в неграмотном юзании параметров пакетных заданий
9. и т.п.