ЗУП 3.0. Что за новый файл "DoNotCopy.txt" в папке с базой? #757601

Появился после обновления текстовый файл в папке с базой. внутренности: 2d5cf0cb-c822-40c2-baae-ea4ab5a8a508 Файл создан для контроля за перемещением информационной базы в новое место. Если информационная база была перемещается в новое место, то скопируйте этот файл в новый каталог базы (необязательно). Если информационная база перемещается в качестве копии, то этот файл копировать не нужно. Что это за файл такой?

защита от дятлов на уровне платформы, которые забывают отключать регламентные задания в копиях базы.

Хм.. а как это защитит от дятлов, которые скопируют базу вместе с этим файлом? )

Напиши в 1С.

или в спортлото.

от дятлов, уверен? Что происходит с регламентными заданиями, если загружаешь базу из DT в файловую базу? Вот загрузил базу, а в ней прописаны разные синхронизации по регламентным заданиями. Как их отключить до того как оно хоть раз сработает? ИМХО в стандартной синхронизации очень не хватает настройки, в которой указать рабочий сервер и рабочую базу. (а еще лучше настройку на уровне всей базы сразу). Указывать это надо вручную в явном виде, тогда и не нужны будут всякие костыли.

я уже давно использую следующий код

у тебя только один сервер?

плюсую. сколько раз спотыкался на этом)

нет, не один... работает замечательно... единственный минус - не работает если часть зверей ломятся по IP а часть по имени

да я к тому, что нужно еще и проверять имя сервера. Иначе развернешь копию с тем же именем на новом сервере и база определится как рабочая.

ты код посмотри сначала .... конечно там есть варианты с файловой базой, но учитывая, что путь полный (их совсем мало и они только для файловой базы)

/AllowExecuteScheduledJobs -Off|-Force  — управление запуском регламентных заданий. Регламентные задания начинают выполняться на первом запущенном по порядку клиенте, у которого не AllowExecuteScheduledJobs –Off. После завершения сеанса этого клиента, выполнение переходит к какому-либо из других запущенных сеансов. Если запускается сеанс с AllowExecuteScheduledJobs –Force, то регламентные задания начинают выполняться на нем, не зависимо от наличия других сеансов.

ок. внимательно код не прочитал, косяк.

/AllowExecuteScheduledJobs -Off  действительно вариант. Спасибо о таком варианте не подумал. но ИМХО нужен штатный способ на уровне конфигурации указать имя рабочей базы и рабочего сервера.

Слишком легко забыть отключить регламентные задания. Особенно когда 99% времени работает в одном варианте (например, в клиент-серверном) и один раз понадобилось использовать другой вариант (например, файловый).

я думал привязаться к ID базы в кластере (имя каталога с серверным кешем), но при использования кластера это не работает. а еще есть вариант когда вообще ничего не спасет - это клон виртуалки... короче на 100% гарантию нельзя получить (тут с месяц назад был топ на эту тему) по этому штатную не сделают никогда, что бы к ним претензий не было... мой вариант дает вполне сносную работу в подавляющем большинстве окружений и реально помогает не только мне но и пользователям (не путаться где тестовая копия а где рабочая)

твой вариант (собственно у меня тоже есть такой вариант) обладает только одним недостатком. А именно: нужно вносить изменения в базу. А это плохо.

Всё было бы гораздо проще, если бы "по умолчанию" в новых базах регламентные задания были бы запрещены и их приходилось бы разрешать "вручную". Имхо.

когда создаешь базу в кластере - ставь галочку "блокировка регламентных заданий" и уже можешь не парится, что при копировании в эту бузу, что-то заработает... ну а файловые - так они только для демо и подходят... вообще для них нужно запретить рег задания и сделать только монопольный режим...

Да, так было бы лучше.

ага... купил себе бух базу, установил - запустил. и не работает.

пойди этому буху объясни, какие регламентные задания и как запустить. но это, конечно, тоже решаемо

Кто знает, где есть описание "DoNotCopy.txt"? на its не нашел :( в доке тоже.

я имею ввиду когда появляется, да чего действует.

Спасибо, кэп :) я об этом и говорил. Было бы лучше, имхо, чтобы в кластере(а ещё лучше - на уровне платформы) там была ба галочка возле пункта "Разрешить выполнение заданий", а не блокировать. Первоначальное заполнение базы - куда сложнее процесс, но ведь делают. вот там самое место разрешению выполнять задания.

лезешь в консоль, снимаешь галку. все просто.

под словосочетанием "бух базу" я имел ввиду "бухгалтер базу". т.е. базу купил не программист, а обычный пользователь, которые не знает никаких консолей.

и развернул кластер 1С? где для файловой консоль?

забей.

для файловой и так с плясками надо рег.задания настраивать. и на файловую вообще пох. речь о сервере.

"ну а файловые - так они только для демо и подходят" - РИБ-базы, где центральный узел на SQL и куча файловых подчиненных узлов в "ларьках" - имхо, до сих пор широко распространенный вариант.

и какой умник будет делать копию узла и на нем поработать??? в такой ситуации вообще должны жестко запрещены любые манипуляции с узлом

Я для себя решил задачу обмена данными, путем создания обработки-шаблона. Обработка подключается как доп.обработка (БСП). В обработке 2 команды (все создается автоматом). Одна на открытие формы (для настройки и ручной выгрузки) вторая на запуск в виде регламентного задания. Как итог: Пишешь правила в КД 2.1. Эти правила загружаешь в макет обработки (либо выкладываешь в сетевую папку, как удобннее). Настраиваешь обработку и дальше все работает автоматом.  Настройка шаблона (при наличии готовых правил) занимает минуты 3-4. вот так вот это выглядит (настройка): вот так выглядит ручная выгрузка (это все одна форма, просто настройки скрываются после их сохранения): без указания плана обмена документы вручную выбираются. если указан план обмена, то берутся по плану обмена. соответственно все работает без изменения конфигурации.

предлагаешь в каждую базу добавить константу ИдентификаторРабочейБазы?

PS: у баз данных уже есть к чему "привязать" выполнение заданий - так называемый "внутренний уникальный идентификатор" - он в пути к кэшам используется. Для кластера он на сервере, для файловых - локальный для пользователя, настроенного под выполнение регламентов.

Не знаю у кого как, а у меня это обычное дело. Когда в ЗУПе новые начисления/удержания прописывают - просят копию, чтобы там отработать варианты формул (с прогоном на реальных данных); технологи и конструктора в УПП, когда опытные образцы нового изделия отрабатывают - просят копию для контрольного прогона, вплоть до расчета себестоимости...

Извиняюсь, проверка на уровне конфигурации

Спасибо, за информацию. не нашел сам :(

значит это только для бухии и с определенного релиза... мало, но уже хлеб.

в принципе вполне подходящее решение, всегда напрягало в копиях отключать обмены автоматические. Остается только один вопрос, если отключил, а потом надо включить обратно? Под рукой нет подходящего релиза