Баг или не баг?

[Murlin]

Цитата:

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

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

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

что именно опасного? т.е. действительно "опасного" а не то что вы с формы не перейдете на другую форму. relation - да
код вида
inventTrans.TransType > a и inventTrans.TransType < b
по большим сомнением... Т.к. выпуская sp с новым enumом
я думаю в нем будет исправление
inventTrans.transtype>a и inventTrans.TransType<c

[dech]

Цитата:

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

что именно опасного? т.е. действительно "опасного" а не то что вы с формы не перейдете на другую форму. relation - да
код вида
inventTrans.TransType > a и inventTrans.TransType < b
по большим сомнением... Т.к. выпуская sp с новым enumом
я думаю в нем будет исправление
inventTrans.transtype>a и inventTrans.TransType<c

Скорее всего вы не найдёте в системе таких енумов, где значение b является последним, а уж тем более, где между a и b есть разрыв. Обновление таких енумов не затрёт старые значения, а только лишь дополнит. Так что такой код ошибку не вызовет, хоть он и написан не очень корректно. Кстати, мне встречался такой код, где был добавлен новый элемент в енум, причем в коде забыли прописать подобную строку:

inventTrans.transtype>a && inventTrans.TransType<c

Приходилось самому исправлять.