[sukhanchik]

Цитата:

Сообщение от S.Kuskov

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

Почему так делать опасно уже здесь написали, но видимо недостаточно убедительно

Ааа.... возможно я не так понял. Тогда да, апгрейд-скрипты конечно не нужны и проблемы только в коде. Хотя останется 2 проблемы:
1. Ситуация со знаками > и < (я про это писал) при сравнении значений енумов
2. Ситуация, когда вместо перечисления конкретных значений енума - указывается отрицание оставшихся значений. Ну, к примеру, можно написать:

switch (x)
{
      case 1,2,3:
..................
      default: 
}

А можно написать так:

if (x !=4)

Но это все проблемы именно анализа кода, а не данных.
Предопределенные данные могут возникать тогда, когда эти данные выпускает сам МС. Например, шаблоны отчетов для генератора финотчетности (ГФО). Тут конечно нельзя так просто отбросить именно МС-овские енумы.

Также тут надо понимать масштабы обновлений. Одно дело сервис-пак, который вообще могут не ставить, а только вытащить отдельные нужные куски.
Другое дело - апгрейд на новую версию. В новой версии - значения енумов скорее всего сохранятся. И там уже так просто не перебьешь.
И еще момент - с т.з. сравнения элементов в АОТе - удобнее, когда мало объектов, которые расположены на слое от МСа и на своем слое. В этом плане - проще не МСный код править (для исправления значения енума), а свой, чтобы не увеличивать количество объектов, расположенных на нескольких слоях.

Так что если не смотреть вперед на обновление версий - то, в общем-то вариант, когда при конфликте значений берется значение не от МС - вполне жизнеспособен.