В целях экономии времени на внедрение, приходится работать непосредственно с рабочей базой. Изменения необходимо отработать на тестовых записях и желательно(точнее обязательно), чтобы эти записи не влияли на итоги, отчёты, реестры, т.е. чтобы они были видимы только для разработчиков. Чтобы было понятно о чём речь, приведу пример.
Все тестовые записи во всех разделах с общим полем "Name" именуются начиная с символа "@", например @Иванов Петрович или @Договор и т.д. В представлениях (View) для основных таблиц разделов изменяем условия выборки, исключаем тестовые записи для пользователей, которые не входят в группу разработчиков (AdminUnit).
Всё работает, но есть недостатки. Если учётная запись имеет признак "Администратор", то выборка идёт минуя представления. Также при сохранении сервиса таблицы представление будет перезаписано.
Может у кого был подобный опыт?
Нравится
Имхо делать доработки на боевой базе нехорошо и неправильно. Тем более схема уж очень сложная выходить, View переписывать и прочее, пожалейте собственное время:smile:
Сделайте себе копию базы для проведения доработок и их отладки, а затем выгружайте измененные сервисы в боевую.
Вариант автоматизации процесса - PVC http://community.terrasoft.ua/catalog/4245, всячески рекомендую.
Как сказал Александр Кудряшов, лучше не делать доработки на основной базе...
Только на этой неделе положил рабочую базу:sad:
Это итерационный процесс - сделали изменения на базе разработки, проверили силами программистов/тестировщиков, выгрузили изменения в рабочую базу. По замечаниям пользователей снова изменили базу разработки, и т.д.
Да делать доработки и тестировать их на рабочей базе плохо бла бла .. но можно во как:
базовый скрипт BaseGridArea поправить малость. вынести на открытие датасета следующий функционал. Создавать для датасета фильтр типа not CreateByID in (список ИД разработчиков) and not ModifiedByID in (список ИД разработчиков).
Костыль канеша, но, елки, разные ситуации бывают.