Групповое заполнение поля.

[nsoft]

Добрый день всем.
Система CRM 4 с обновлением 6
Суть проблемы: В одном из объектов добавили новый атрибут (picklist) и сделали его обязательным к заполнению.
В базе при этом присутствуют около 5600 записей этого объекта.
Как можно заполнить этот атрибут в этих записях обработкой, а не перебирать каждую запись в ручную.

[a33ik]

Добрый день. Есть несколько путей:

1. Поддерживаемый. В CRM есть такое понятие, как групповое редактирование - открыли представление, выбрали записи - Действия - Редактировать - открылось окно - отредактировали, сохранили и данное изменение применяется ко всем выбранным записям.
2. Поддерживаемый. Нужен программист, который сможет написать микроприложение, которое переберёт все записи и обновит поле нужным знеачением.
3. Неподдерживаемый, но безспорно самый удобный. Обновляете это поле при помощи скрипта такого вида: Update <название сущности> Set <название поля> = <значение>

[nsoft]

Насчет 2.3 ну я так уже и понял.
Но надежду вселил 1 пункт.
Правда столкнулся с проблемой зашел в представление выбрал записи, а в действиях у меня только открыть общий доступ, копировать ярлык и отправить ярлык.
Где нить настраивается действия для выбранного представления или нет?

[slivka_83]

Массовое редактирование доступно для ограниченного круга объектов. Не настраивается.
Но, можете cоздать простой Бизнес-процесс, которые по условию проставляет нужное Вам поле и применить его (вручную) к Вашим записям. У Вас их > 5000 - так что два десятка раз запустите (по 250 записей за раз) Можно конечно увеличить лимит с 250 до N - но овчинка не стоит выделки

[Артем Enot Грунин]

К сожалению, групповое редактирование работает не со всеми типами записей, а для тех с которыми работает доступны для изменения не все поля. Кроме того, если у вас 5600 записей, то можно смело забыть про это решение, так как в списке придется выбирать по 250 записей. Остаются пункты 2 и 3.
p.s. Просто для справки. Если не работает групповое редактирование, то для массового изменения записей можно использовать рабочий процесс. Минус тот же за раз получается обработать не больше 250 записей.

[a33ik]

Что за объект такой волшебный? А вообще прямой апдейт - самое верное решение. Использовал, использую и буду использовать. Случаи когда на это поле что то завязано - не рассматриваются.

[nsoft]

Спасибо ребят за то что ответили в этой теме.
Данный объект про который спрашиваеш a33ik называется "Предложение" был неоднократно модернизирован и изменен.
Проблему пришлось решить прямым sql запросом. Хотя на многих форумах читал что прямое изменение может привести к сбоям работы crm пока тфу тфу тфу сбоя не было после прямого запроса.
Бэкап базы был сделан перед началом изменения сейчас думаю развернуть себе копию базы на другом компе и поднять crm.

[Артем Enot Грунин]

Итак, методология ансапорта или запрещенных изменений касательно прямых запросов к базе.
1. Селекты безопасны
2. Апдейты допустимы в большинстве случаев.
3. Инсерты категорически не допустимы в большинстве случаев.

В чем отличие между прямым запросом или запросом через SDK?
1. Не произойдут системные события: на изменения не будут вызваны плагины или рабочие процессы.
2. Не сработают системные механизмы: не обновятся вычисляемые поля, проверка целостности данных и пр.
3. Прямые запросы работают быстрее и позволяют изменять данные массово, а не индивидуально, как в случае с сервисами. Тем не менее, рекомендую использовать их только в крайнем случае.

Отсюда выводы: если вам не нужно, чтобы проснулись плагины, вы уверены, что данное поле не участвует в каких-то системных процессах, например, это ваше кастомное поле, то изменения допустимы.

[nsoft]

Цитата:

Сообщение от Артем Enot Грунин

Итак, методология ансапорта или запрещенных изменений касательно прямых запросов к базе.
1. Селекты безопасны
2. Апдейты допустимы в большинстве случаев.
3. Инсерты категорически не допустимы в большинстве случаев.

В чем отличие между прямым запросом или запросом через SDK?
1. Не произойдут системные события: на изменения не будут вызваны плагины или рабочие процессы.
2. Не сработают системные механизмы: не обновятся вычисляемые поля, проверка целостности данных и пр.
3. Прямые запросы работают быстрее и позволяют изменять данные массово, а не индивидуально, как в случае с сервисами. Тем не менее, рекомендую использовать их только в крайнем случае.

Отсюда выводы: если вам не нужно, чтобы проснулись плагины, вы уверены, что данное поле не участвует в каких-то системных процессах, например, это ваше кастомное поле, то изменения допустимы.

Да Артем я как раз из за этого с этим полем и боялся делать прямой запрос в sql но так как это поле чисто только информационное, только для отчетов вывод информации (оно не вычисляемое) дальнейшего движения ни какого не делает в процессах.

Щя сижу и вкуриваю SDK.