Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Нас несколько разработчиков мы пока работаем не через хранилище конфигураций, но в ближайшее время, надеюсь, перейдём.
Проблема такая.
Каждый разработчик периодически подливает свои разработки со своей локальной базы на рабочую путем сравнения и объединения конфигураций.
Также периодически каждый разработчик загружает на свою локальную базу рабочую dt-шку.
Через некоторое время, при выполнении операции "сравнения и объединения с конфигурацией из файла" стала возникать ошибка с сообщением типа "подождите идёт создание дампа...", сообщение отображается пару секунд после чего конфигуратор закрывается. При повторных попытках сравнения процесс доходит до того же документа и ошибка повторяется.
Мы смогли решить эту проблему, но процесс обхода этой ошибки долгий.
ИЗ-ЗА ЧЕГО ВОЗНИКАЕТ ДАННАЯ ОШИБКА? - Такое ощущение, что происходит какое то рассогласование между dt-шками локальных и рабочей БД
Для решения проблемы, разработчику приходиться в своей конфигурации удалять документ (на сравнении которого приходится сбой) снова выгружать файл конфигурации и опять сравнивать, объединять.
Испробовали много вариантов решения этой проблемы, например:
1.выгрузка, загрузка dt-шки и на рабочей на локальной базах;
2.выгрузка с рабочей cf, сравнение и объединение её с локальной конфигурацией, и выгрузка cf-ки с локальной;
3.Загрузка cf-ки в новую чистую БД и повторная выгрузка с новой;
4.Загрузка dt-шки предыдущей версии БД в новую БД, сравнения cf-ки с ней и выгрузка cf-ки с новой БД;
и другие подобные методы,
но помогает только один способ – удаления объекта.
Раньше ошибки при сравнении возникали редко и мы терпели эти проблемы, а щас возникает раз в неделю.
подливка в основном идёт по сети, но пробовали и локально
всё равно, если ошибка появилась, то вылетает и при локальной подливке и при сетевой подливке.
Скорее всего сама платформа у Вас устаревшая. На 10-х и 11-х релизах такая ошибка постоянно возникала при динамических обновлениях. Обновите платформу 1С до последней (вот у нас щас 13.41).
И постарайтесь реже обновлять рабочую конфу динамически. Это может приводить к утечкам ресурсов на сервере 1С в случае сбоев.
Кстати, когда у Вас возникает такая трабла с дампом, имейте в виду, что на сервере 1С в этот момент происходит утечка памяти. Это плохо.
Было у нас такое. Решилось только переходом на хранилище. Это гораздо проще, чем разбираться в причинах сбоя.
А основная проблема в том, что у вас 2 разработчика одновременно могут добавлять новые объекты в конфигурацию. Хранилище такую возможность блокирует.
Абсолютно согласен. При создании новых объектов в отдельных базах разработчиков система присваивает один и тот же ID разным объектам, естесственно при слиянии воедино всего этого хозяйства возникает аварийная ситуация.
Дионис, без хранилища Вам не обойтись!
В принципе, можно реализовать безошибочную работу и без хранилища.
Но тогда разработчик А, решивший добавить объекты, должен оповестить всех об этом, выполнить добавление, объединение с рабочим dt, известить о завершении работы, после чего все принудительно обязаны обновиться из рабочего файла.
Дык в принципе можно всё и на рабочей базе делать)). Хранилище же и задумывалось как инструмент командной разработки, с тем чтобы избежать подобных рассинхронизаций.
Estel Iкстати, платформу замените на 13._41_ . 37-я как бы нехороша ;)
Аналогичныеситуации бывали, когда сравнивались конифгурации, сохраннные разными версиями платформ (последний раз помню - 8.1.8.67 и 8.1.10.что-то-там)
У всех разработчиков - одна версия.
(а платформы мы так резво не меняем, а со временем естесственно обновим)
Не согласен с коллегами, которые считают, что скорее всего проблема в назначении не уникального ID на локальных конфигах, при создании новых объектов. Против этой версии говорит то, что мы усиленно работали на локальных конфигурациях 3 месяца и таких проблем не было, а теперь появилась.
Причем 1С ругается только на один и тот же объект!
Который приходиться удалять на подливаемой конфиге. А правку этого объекта (документа) производить на боевой конфигурации.
После чего мы выгружаем dt-шку - загружаем на локальных и дальнейшую разработку делаем на обновлённой конфиге!
Но дня через 3-4 опять при сравнении ругается на это же документ.
Вообщем, сейчас мы дружно перешли на хранилище и забыли про эту проблему :)
усиленно работали - означет то, что мы создавали множество новых объектов, независимо друг от друга (9 программистов), а потом подливались на боевую конфигурацию сравнениме и объединением.
Позже месяца через 2, моя группа программистов из 3 человек перешла на работу с хранилищем (не связанную с боевой конфигурацией), а остальные продолжали разработку отдельно!
