Всем привет!
Есть пользовательская БД (тестовая), которую нужно периодически обновлять из другой, рабочей БД.
Но при этом в тестовой БД нужно сделать конвертацию некоторых данных.
Проблема в том, что конвертацию нужно сделать до того, как в базу сможет войти пользователь. Как это реализовать?
База на MS SQL, самый очевидный путь - это сделать скрипт на SQL, который меняет данные прямо в таблицах БД SQL, и запускать этот скрипт сразу после рестора тестовой БД из бэкапа средствами SQL.
Но, это нарушает лицензионное соглашение 1С , а также требует специальных знаний и постоянного отслеживания структуры БД после каждого обновления релиза.
Что тут можно придумать?
Думал над блокировкой сеансов, но ведь при этом надо дать код доступа тому сеансу, который будет конвертировать данные. Т.е. этот код в явном виде будет прописан в строке запуска допустим планировщика виндовс.
Может есть у кого идеи?

(0) посмотреть, как в БСП сделано обновление конфигурации

(1) +1
монопольные обработчики

Уже придумана программка Обновлятор-1С. Доступно и всерьёз.

Слишком абстрактно озвучена задача. Решение может отличаться от типовой конфигурации. В (1) сказано о БСП, но в топике о наличии какого-то БСП ни слова.

Абстрактно : есть предопределенные обработчики, которые разбирают параметры запуска сеанса.
Примерно туда вставлены вызовы для проверки версии платформы, обработки процедур обновления и т.д.

(1) поддерживаю, самый правильный вариант

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

всё-таки наверно сделать риб из этих двух баз.

(6) ты теперь любую ветку будешь пытаться в гениальный срач превращать?

(7) я тоже так подумал, но такой РИБ на практике может оказаться трудно сделать, поскольку не обозначено под какую конфу им это нужно.

Когда ТС проснётся, расскажет нам для чего в тестовой базе кроме обновления нужна конвертация данных

(10) было бы вообще неплохо понять, что именно понимается под этой "конвертацией данных"
а то может речь о анонимизации данных, чтобы поменять всё названия номенклатуры на Товар1, Товар2,Товар3...., а названия контрагентов на Котнтрагент1, Контрагент2...

Очень просто.
Создаем в базе специального пользовптеля.
При запуске,проверяем,если специальный пользовптель,то зарускаем обработку в монопольном режиме.
Специальный пользователь - для того,чтобы иметь права на все объекты,которые нужно изменить.
Далее,из рабочей выгружаем backup.
Загружаем его в служебную базу.
Запускаем служебную базу аод специальным пользователем любым способом.
После окончания обработки удаляем тестовую базу и заменяем ее служебной.
Если что-то не отработало,то тестовая будет старее,но будет доступна без проблем.

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

(12) а потом какой-нибудь м... запусит рабочую под специальным пользователем

(14) Ну и что?
Если все сделано правильно,то в журнал будет записана ошибка и показана пользователю,что на данной базк этот функционал не работает.
Не забываем,что серверная база,если не отключены регламенты,начинает выполнять обмены,и они должны работать только в рабочей базе.

(15) причем тут регламенты, он же вручную будет обмен пускать. Это же разово запускается. Раз в месяц, например. По желанию.

(0) две копии баз сделай
0 - исходная рабочая будет
1 - чистая копия средствами sql
2 - правленная копия средствами 1С через монопольную обработку 1-й копии (там удобно что юзеров кроме "робота" никого) и выгрузки во вторую

(17)+ в итоге в 0-й юзеры, в 1-й только робот, во 2-й разрабы/тестеры

Извиняюсь, был без доступа в инет.
(11) Да, речь об анонимизации, типа того что пишете.
Все предложения как я понял основаны на том, что базу можно запустить средствами 1С, но админы не хотят давать доступ к базе, пока данные в ней не конвертированы. (16) Ничего вручную не будет. В том и дело, что будет настроен бэкап, копирование, рестор базы. Но это делают админы, и политика безопасности запрещает им делать рестор на тест, если в базе реальные данные. В идеале, чтобы скрипт на SQL это делал, и админы бы его прикрутили к процедуре рестора. После чего только открыли бы доступ к базе.
(18) Поясни пожалуйста, как получается п.1 - чистая копия средствами SQL. Почему в ней только робот? На каком этапе удалены все другие пользователи, кто это сделал?

(19) на ИТС в инструментах разработчика должна быть штатная обработка СкрытиеКонфиденциальнойИнформации.epf

(20) Обработку и свою напишем. Проблема в том, как её запустить, если базу нельзя сделать активной до того как данные будут исправлены

(21) в любом случае, каким-бы извратом не пользовались, не запустите ничего - нужен запуск в режиме Предприятия.

Вы решаете проблему несколько извращенным способом.

Но способов достичь желаемого (сделать базу для тестирования) даже несколько. Но любой из способов будет отрабатывать только в режиме Предприятие.

Ваши админы "не хотят"... Так они и бакапы базы делать не должны разрешать, потому что база в бакапе содержит все нужные данные :-)))

И обмены из базы делать нельзя - там же данные !!!

Я же вам писал,служебная база.
К ней никто,кроме самих админов доступа иметь не должен.
А когда она стала готова,то она переносится тестовую,причем можно также методом backup-restore.

(24) бе-бе-бе :-)))))

(0) https://i.imgur.com/WgqvzdG.png
https://i.imgur.com/brM1Yr3.png

(24) "К ней никто,кроме самих админов доступа иметь не должен." - это как реализовать, чтобы после рестора БД стала доступна только админам... Доступ к БД делается на уровне прав учетки SQL, под которой 1С ходит в БД. Если блокируем эту учетку, то и админы не войдут. А если разрешаем, то любой войдет, зная имя сервера и имя ИБ.

(26) У нас на копии нужны некоторые регламентные задания, они там тоже тестируются, поэтому наверное не подойдет

(27) во-первых,при восстановлении можно использовать другого пользователя sql,пароль от которого знают только специальные люди.
во-вторых,можно выполнять все действия на копии сервера 1с,к которому доступ только локально,тогда к этой базе никто подключиться не может.
Что касается регламентов,то можно в базе определить другое расписание и поменять настройки подключения,тогда база ни в какие рабочие обмены не полезет.

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

(29) "во-первых, при восстановлении можно использовать другого пользователя sql,пароль от которого знают только специальные люди."
Это не поможет, поскольку пароль SQL вводится 1 раз при создании ИБ в консоли сервера 1С. А дальше, если ты имеешь доступ к консоли сервера, то ты знаешь имя базы и сервер, и пароль SQL тебе не нужен, чтоб зайти в базу.

"во-вторых,можно выполнять все действия на копии сервера 1с,к которому доступ только локально,тогда к этой базе никто подключиться не может."
Вот это очень интересно, спасибо. Но я не совсем понял, что это значит) Сервер 1С установлен на сервере приложений, куда всем разработчикам есть доступ по RDP. Т.е. получается у всех разработчиков локальный доступ есть? Это имели ввиду?

(0) Может вам нужно обезличить персональные данные, но вы стесняетесь это озвучить? :)

(31) он это уже озвучил в постах. Вся проблема его топика в том, что _любые_ действия над данными в базах 1С выполняются корректно только когда 1С в режиме Предприятие _открыта_.

А тс не желает ни под какими вариантами и нигде более это сделать.
Копирует базу средствами СУБД и тут же ожидает до запуска 1С изменение данных, т.е. обезличивание.
Более того, он еще вероятно ожидает, что из базы будут удалены все пользователи ИБ.
и т.д. и т.п.

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

(28) Отключить регзадания на кластере 1с перед деплоем бэкапа не?
Проверять перед началом работы, прод ли это, и, если нет, выводить окно очистки конфиденциальных данных?

(34)В самописных регзаданиях добавить проверку на прод перед стартом.

(35) При полном недоверии безопасности схд хранить дампы SQL таблиц с критичной инфой отдельно от архивов, выгрузка через промежуточную базу с предварительной очисткой конфиденциальных данных