Как "отличить" базу от ее копии?:) #681196

Здравствуйте! В-общем, есть база 1С, настроен РИБ с несколькими дочерними узлами. Между базами ходят файлы типа "Message_000_001.zip". Назовем этот набор баз "Система №1". Теперь берем и копируем центральную базу и создаем новые узлы. Назовем эту систему "Система №2". Теперь вопрос - как сделать так, чтобы юзеры не путали файлы "Message_000_001" из системы №1 и системы №2? Иначе говоря, как сделать так, чтобы при попытке загрузки файла обмена из первой системы во вторую вываливалась ошибка, что файл обмена не от этой базы? Смотрел выгружаемый XML, думаю дело в v8de:Signature или v8de:Digest, но как ее изменить? Пробовал создавать вторую базу выгрузкой/загрузкой *.cf из первой, думал, что эти уникальные значения генерируются при создании базы, но не помогает, значения те же.

настрой другой каталог обмена да и все

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

Коды узлов можно поменять.

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

Ведь каждая база 1С имеет что-то, отличающее ее от других? Кроме различия в структуре, типа УникальногоИдентификатора для объектов

"юзверь перепутает каталоги" на каждую базу 1С - свой терминальный сервер

имя сервера и имя базы на сервере

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

Ну конфигурацию поменяй. Фиг загрузиться.

Маркировать файл обмена надо как-то, вестимо. У автора вопрос: как это делать или чем уникальным это делать?

как случилось, что пользователи руками выбирают файлы и нажимают кнопки, вместо автоматического обмена ?

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

Файлы обмена им приходят по электронной почте, в теле письма написано "обмен для системы №1".

Реквизит в плане обмена или сохраненная настройка.

форум должен угадать какими средствами файл обмена строиться ?

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

ещё раз [как случилось, что пользователи руками выбирают файлы и нажимают кнопки, вместо автоматического обмена ?]

настрой им почтового клиента , что бы файл "обмен для системы №2" удаляся

процесс делания копии нужно регламентировать так, чтобы сразу после создания она обезвреживалась. То есть, чтобы там очищались все источники данных, заглушались регламентные задания, чистились пути к продуктивным всяким тёплым местам.

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

Обмен самый что ни на есть стандартный РИБ -ПланОбмена.ПрочитатьИзменения и ПланОбмена.ЗаписатьИзменения. Через да, можно автоматизировать обмен, чтобы юзер не касался файлов обмена. Но это дополнительные трудозатраты, FTP-сервер поднимать или писать код обмена через email. Да и нужно это не навсегда, а на какое-то время. , - да нет, тут регламентные задания не при чем. Обмен  практически ручной (как самый простой) - получили файл, открепили, выложили в каталог, запустили обмен, выгруженный файл из каталога отправили обратно.

про v8de:Signature или v8de:Digest никто ничего не скажет?

Всё не читал. Сделай, что бы во всех системах не было повторяющихся кодов узлов. Никакой путаницы не будет. Если сделать обмен по фтп. То даже с файлами не придется возиться.

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

сделай константу, забей туда параметры соединения с ИБ.

Это идея, с другими номерами сообщений... "По сигнатуре, насколько я понимаю проверяться идентичность конфигураций" - ВОТ да, об этом я! Т.е. получается, что две отдельно созданные конфигурации но с одинаковым составом справочников и реквизитов буду иметь одинаковую сигнатуру? И тогда ее нельзя считать уникальной?

Ну да. И это легко проверяется. Скопировать базу и сделать выгрузку в обеих базах. v8de:Signature и v8de:Digest будут идентичны.

префикс добавить узлам предлагали?

префикс узлов менять по сравнению с системой №1 нельзя.

а если не копировать базу, а создать новую с теми же объектами? Тогда сигнатура новой будет одинакова с исходной?

почему? ... кстати в копии еще можно счетчик обнулить ...

ну измените наименование сообщения, будет у вас не "Message_000_001" а "MessageТ_000_001" или как вариант - вы ведь архивируете сообщения - ну так и устанавливайте пароль на архив, и в каждой базе будет свой пароль

Константу. В ней уникальный идентификатор каждой базы

Вот с паролем самое то! ничего менять не надо, только в настройке обмена пароль прописать! Я бы сказал гениально!:) Менять "Message" можно, но это прописано в коде типовой бухгалтерии, а в типовой код не хотелось бы лезть. Сложновато, по сравнению с установкой пароля на архив:)

Спасибо всем сочуствующим! Вариант с паролем на файл обмена самое то, если конечно у кого-то нет идеи еще круче, например как изменить сигнатуру базы:) Еще раз спасибо всем, и Vovan1975 в частности!

На практике используем СтрокаСоединения для идентификации, как уже выше и писали, нормальный способ

если поменять только пароль - базы будут обмениваться через раз. Если обмен через каталог, файлы одной системы будут перезаписывать файлы другой; правильней всё-таки поменять пути/почтовые ящики/ftp

никто еще не написал что ли? СтрокаСоединенияИнформационнойБазы

Верно. Константа хранит строку соединения. Сравниваем получившуюся строку с константой и получаем копия это или нет. Я обычно при этом еще цветовую тему автоматом менял, чтобы понятнее визуально было

Теоретически можно поднять сервер с тем же именем и именем базы. ГУИД более универсально Или СтрокаСоединенияИнформационнойБазы + Гуид

гуид чего?

Просто ГУИД формирующийся при первом запуске базы Например Новый уникальныйидентификатор

Ничего не понял. Есть база. При первом запуске ей дался какой то гуид. Делаем с базы копию. Копия свой запуск не идентифицирует как первый и у нее остается тот же гуид. Так?