Хранилище конфигурации: не очевидные особенности групповой разработки

03.06.13

Разработка - Групповая разработка (Git, хранилище)

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

Введение

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

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

Базовый порядок работы

Итак, сначала вкратце опишу базовый порядок работы с хранилищем, который используем мы:

  • Рабочая база подключена к хранилищу;
  • Для каждого разработчика создается отдельная копия;
  • Пользователей хранилища мы называем по имени базы на 1с сервере. Пароль всегда стандартный и одинаковый. Это очень удобно. Совершенно не нужно помнить никаких логинов/паролей. Если ты заходишь в конфигуратор рабочей базы, то вводишь в логин имя рабочей, в копии - имена копий;
  • Рабочая база (желательно ежедневно) в ручном или автоматическом режиме обновляется из хранилища;
  • Если в течение дня пришлось что-то аврально исправлять, то можно внести исправление и в рабочей базе, но сразу поместить изменения в хранилище.

 

Особенности

Теперь перейдем к вещам, которые обязательно нужно помнить при работе с хранилищем. Многие из них достаточно очевидны. Однако есть и такие, которые мы “словили”.

Хочу обратить внимание, что основное “словили” заключается в особенностях ведения наших проектов, однако полагаю что для многих это также актуально. У нас есть несколько самописных систем, которые уже эксплуатируются, но также активно дорабатываются. В рабочие конфигурации внедряются новые подсистемы, затрагивающие достаточно большой функционал. При этом, как всегда, всем надо всё и быстро, и мы не можем себе позволить по полгода разрабатывать/тестировать функционал где-то в сторонке, а уже потом внедрять его в рабочие системы. Чаще всего проекты  разбиваются на маленькие и средние задания на разработку. Такое задание попадает к разработчику, он в своей копии пишет то, что надо.  Потом, на его же копии всё тестируется, и если все хорошо, через хранилище обновляется рабочая БД. Не будем останавливаться на том, что так разработку вести не очень хорошо, но что, то есть, и уверен у многих похожие ситуации.

Теперь подробнее о таких особенностях:

 

Правила работы с корнем конфигурации

Правило номер 1: не держите захваченным корень конфигурации!

Тут вроде все достаточно очевидно. Если при разработке необходимо добавить новые объекты, то работаем по следующему алгоритму:

  • Захватываем корень;

  • Добавляем новый объект;

  • Помещаем корень и новый объект;

  • Захватываем объект обратно.

Думаю, многие работают по такому принципу. Вроде удобно, что корень всегда свободен для других разработчиков. Если даже новые объекты обновляются на рабочую - тоже ничего страшного (на них нет прав и их никто не увидит). Однако такой способ, помимо удобства, может содержать не очевидные неожиданности. О которых далее.

 

 

Составные поля - зло

Составные поля содержат в себе несколько неожиданностей при работе с хранилищем при нашей схеме разработки. Приведу несколько примеров.

  • Добавление нового документа. Допустим необходимо добавить новый документ, но он, в свою очередь, является регистратором уже существующего регистра. Если мы пойдем по стандартному пути работы с корнем, вот что нас ждет. Мы добавим документ и поместим его в хранилище, т.е. этот документ появится в рабочей базе. В итоге у поля регистратор существующего регистра добавится новый тип документа, на который, я напоминаю, у пользователей нет прав. Таким образом, в рабочей базе пользователи могут словить “Нарушение прав доступа” при чтении таблицы регистра.

  • Приведу другой похожий пример связанный с нумераторами. Добавляем новый документ и устанавливаем ему существующий нумератор, который уже используется в других документах. Затем также бездумно помещаем этот документ в хранилище. Всё, при записи любого документа, которому установлен данный нумератор ловим нарушение прав доступа на все тоже чтение нового документа.

Правило номер 2: думайте о составных полях и правах. Не помещайте объекты в хранилище бездумно!

 

Правила работы с ролями

С ролями всегда нужно работать аккуратно. Ни в коем случае нельзя надолго захватывать существующую роль. Захватил роль-->добавил права-->поместил обратно. К сожалению, так случается, что работа над какой-либо задачей затягивается и у разработчика в его копии остается много захваченных объектов. Это в принципе не критично, но не в случае с ролями. С большой вероятностью, случится ситуация, при которой другому разработчику понадобится срочно роль.

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

 


 

Особо хочу отметить очень не очевидную проблему при работе с ролями вроде ПолныеПрава или Администратор. В общем с любыми ролями, у которых установлен флаг “Устанавливать права для новых объектов”:

 

 

Сначала сформулирую правило номер 3: старайтесь никогда не захватывать в хранилище роль ПолныеПрава!

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

Так почему же не надо захватывать такие роли?

Ну, во-первых, в большинстве случаев это просто не нужно.

Во-вторых, все таки случаются ситуации при которых такую роль захватить надо. Обычно это происходит тогда, когда нужно снять какие-то права у данной роли. Вот тут-то и зарыта опасность. Мы захватили такую роль. В это время другой разработчик добавил новый объект и поместил его в хранилище. Мы закончили редактировать роль и поместили его в хранилище. И, бац, у роли ПолныеПрава нет прав на новый объект, потому что мы их перезатёрли. Неопрятная неожиданность.

 

Дополнительные полезные советы:

  • Старайтесь помещать объекты в хранилище не по одному, а “пакетом”: все объекты, измененные в рамках одной задачи.

Во-первых, это уменьшает вероятность ошибок “целостности”. Я о них подробно и не говорил, потому как это должно быть более менее очевидно. Если мы изменили обработку проведения документа, из которой вызывали процедуру общего модуля, то нужно поместить и документ, и общий модуль.

Во-вторых, позволяет проще ориентироваться в версиях конфигурации. Тут я советую также пользоваться метками для версии в хранилище.

  • Пользуйтесь окном “Хранилище конфигурации”. К сожалению, почему-то не все знают о его существовании. А тем не менее, оно очень полезное. Например, в нем можно пакетно захватывать, помещать объекты в хранилище (через ctrl), ставить отборы (Все захваченные и Все захваченные пользователем).

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

 

 

  • При какой-либо не удачной попытке подключения к хранилищу (например, Вы случайно нажали отмена при подключении), 1С выдаст Вам вот такой диалог:

 

 

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

  • Пользуйтесь снегопатом! В скриптах снегопата реализованы удобные фичи для работы с хранилищем, например: автоподключение к хранилищу (не надо каждый раз вводить пароль), захват текущего элемента в хранилище.

 

Спасибо за внимание, надеюсь для кого-то информация окажется полезной. У кого есть что добавить, добро пожаловать в комментарии.

См. также

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9144    78    4    

110

Особенности национального Workflow: Github Actions и OneScript

Групповая разработка (Git, хранилище) OneScript Бесплатно (free)

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    1189    bayselonarrend    3    

37

Автоматизация процесса разработки с помощью сервиса GitFlic

Групповая разработка (Git, хранилище) Бесплатно (free)

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    1866    user1989937    6    

15

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

Групповая разработка (Git, хранилище) Бесплатно (free)

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    3780    bayselonarrend    15    

61

Насколько глубок 1С-ный GitHub?

Групповая разработка (Git, хранилище) Бесплатно (free)

Open-source проекты - важная часть мира программного обеспечения. 1С привычно держится немного в стороне от глобальных трендов, но бросить холодный статистический взгляд на положение дел мне показалось небезынтересным.

22.01.2024    7844    bayselonarrend    50    

86

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2774    kamisov    17    

57

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

Групповая разработка (Git, хранилище) Бесплатно (free)

Хранилище конфигурации 1С - это инструмент групповой разработки. Работают с хранилищем следующим образом: захватывают какой-либо объект, редактируют, потом отдают его в хранилище. Хранилище помечает уже захваченные объекты и не дает возможности захватить их другим пользователям. Это рождает и самый большой недостаток хранилища - невозможность работы с одним объектом нескольких пользователей, например в случае доработки разных методов в одном большом модуле. Корень конфигурации - это самый верхний ее узел. Только захватив корень, мы можем добавить в конфигурацию новые общие модули, документы, справочники, регистры и подобное. Только захватив корень можно изменить настройки поддержки конфигурации. Соответственно, если корень захвачен одним программистом, другой программист не может добавить новые объекты или снять что-то с поддержки. Потому то и всплывает эта фраза - отдай корень, мне нужно тоже что-то добавить.

26.12.2023    1336    ardn    1    

26

Git Code Review - инструмент для рецензирования кода

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 1С:ERP Управление предприятием 2 Абонемент ($m)

Git Code Review - инструмент, позволяющий быстро анализировать изменения из git-репозитория прямо в 1С

1 стартмани

20.12.2023    3958    59    salexdv    26    

81
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. kapustinag 03.06.13 12:09 Сейчас в теме
C картинками какая-то проблема. Не отображаются картинки в тексте публикации, только место пустое. В трех доступных мне броузерах посмотрел - везде пусто. Или все-же у меня локальная проблема?
2. _also 484 03.06.13 12:41 Сейчас в теме
(1) kapustinag, проверьте сейчас, пожалуйста.
3. mentos 26 03.06.13 13:56 Сейчас в теме
Пользователей хранилища мы называем по имени базы на 1с сервере.

вот за это спасибо :) простейшая вещь, но в голову никогда не приходила
4. _also 484 03.06.13 14:21 Сейчас в теме
(3) mentos, да, это очень удобно
5. kapustinag 03.06.13 15:43 Сейчас в теме
Похоже, стоит фильтр на нашем прокси-сервере. Картинки-то не на сервере Инфостарта, а на google...
С другого компьютера, внешнего, зашел - все Ок.
6. _also 484 03.06.13 15:47 Сейчас в теме
(5) kapustinag, видимо инфостарт не копирует лишнего на свой сервер. Я в статье делал вставить картинку и указывал url.
7. speshuric 1326 03.06.13 21:20 Сейчас в теме
"Рабочая база подключена к хранилищу;" - после этого читать желание пропало.
8. _also 484 03.06.13 21:24 Сейчас в теме
(7) Поясните свою точку зрения
9. speshuric 1326 03.06.13 22:35 Сейчас в теме
(8) _also
Сразу скажу, что я и сам какое-то время так делал. Пока не переубедил коллег. Я считаю, что вешать продуктовую базу на хранилище - по надёжности это примерно аналог того, что подписаться на автообновления midnight сборок. Правильным вариантом является выплёвывать файлы поставки и держать продуктовую базу у себя на поставке "на замочке". В этом режиме можно обновлять и ежедневно и еженедельно и вообще, как пожелаете.
Лет 5 с лишним назад накидал схемку того, как примерно это выглядит. Нюансов там заметно больше, но для начала обсуждения вполне пойдёт.

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

Если исправления не авральные, то как бонус - можно протестировать именно тот файл поставки, который пойдёт в бой, хотя б "джентельменский набор": синтаксис, проверки конфы, логин админа, логин пользователя, время реструктуризации. Автоматизируется на раз-два, зато не сможете совершить ошибку, которую допустила 1С в релизе УПП 1.2.8:
Исправлена ошибка 00092921:
При входе пользователя не с полными правами происходит ошибка.

Опять же заранее будет видно если косяк с реструктуризацией и т.п.

Я ни в коем случае не спорю с самими советами. И роли, и составные типы, и многие другие советы вполне разумны и интересны, но модель "рабочая на хранилище" меня пугает очень сильно.
Boulala; Дмитрий74Чел; h00k; KapasMordorov; pit201201; omut; kuntashov; bird21; CratosX; Ish_2; laduk; xzorkiix; _also; awk; +14 Ответить
10. _also 484 03.06.13 23:28 Сейчас в теме
(9) speshuric,
держать продуктовую базу у себя на поставке "на замочке"

это мечта. Конкретно в наших реалиях авральных исправлений порой больше, чем нормальных обновлений, так что... НУ не можем мы себе такого позволить.
Спасибо за схемку, подход у Вас очень правильный. Однако я считаю ее слишком тяжелой для случаев небольших баз, с небольшим количеством пользователей, И... с низкоквалифицированными программистами.
В любом случае спасибо за конструктив, этого я и ждал :)
16. speshuric 1326 03.06.13 23:55 Сейчас в теме
(10) Как раз с низкоквалифицированными сотрудниками схема "с поставкой" лучше. Натаскать сервис-деск или кого-то подобной квалификации на проверку и формаирование релиза достаточно просто, а времени высвобождается немало: это и проверка и выгоняние пользователей и само применение. Когда писалась эта схема как раз одна из целей была пульнуть в сопровождателей релизом и самому не греть голову.
(11) pumbaE, Веток не хватает. Git не хватает с распределённой структурой. Есть такое. Но цикл сборка/поставка дисциплинирует вне зависимости от того есть тестировщик или нет. Просто же: собрал, проверил синтаксис и конфу на ошибки, проверил реструктуризацию, проверил логин великого админа и проверил логин твари ничтожной. Да хоть бы и в УПП - это займёт на нормальной железяке около получаса от силы. Не хочешь сам - отдай "подовану", заодно пусть посмотрит изменения и покритикует, если время есть. Выше приведён пример, что и фирма 1С когда-то забивала на эти проверки и к чему это приводило. Не нужен на этом уровне ни билдбот, ни отдельный тестер. Нужен просто этап "Я собрал поставку, я сейчас её накачу и хочу проверить, что мне не придётся сидеть 2 выходных и восстанавливать работу предприятия".

Давайте не будем пенять на 1С и ждать когда она "повернетса к программистам" (кстати, какой стороной? :) ). Хочется, чтобы был идеальный код - начни с себя и своего коллектива. Юнит-тестов не хватает? Так надо писать и показывать на практике результативность этого подхода, другие методы не сработают.
KEV8383; xzorkiix; _also; +3 Ответить
17. _also 484 04.06.13 00:00 Сейчас в теме
(16) speshuric, низкоквалифицированные сотрудники порождают такой код, что придется каждый день с поставки снимать.
За "начни с себя" - огромный плюс. Мы все кивать горазды, а сами производим тот еще.. продукт ((
11. pumbaE 03.06.13 23:32 Сейчас в теме
(9) speshuric, не хватает хранилищу "веток".
Ваша схема подойдет когда все таки проводятса какие-либо автоматические тесты или даже есть отдельный тестировщик или же пользователи проверяют в отдельной тестовой базе данные, перед помещением в рабочую базу.
Но чаще, к сожалению, конечный потребитель доработок является и тестировщиком и пользователем одновременно и об ошибках програмисты узнают утром не от build-бота, а от полоьзователей.

p.s: Имхо, вряд ли что-то изменится кардинально даже с выходом 8.3 и возможности тестирования, если сама 1С не повернетса к программистам и не будет пропогандировать "best practice" среди программистов и будет публиковать тесты к типовым конфигурациям (скептик во мне заявляет "Не бывать этому!"). Возможно будут единицы использовать тесты, чего таить и сам не без греха, но я то постараюсь вместе с Артуром Аюхановым поразрабатывать в стиле TDD , а основаня масса програмистов так и будет писать комментарии в коде "Здесь было Вася" и считать, что это верх совершенства в способах доработок типового кода, а про тестирование даже понятия не иметь.
p.s.s: Я знаю, что автоматическое тестирование - это не волшебная пилюля.
kuntashov; KEV8383; _also; +3 Ответить
12. _also 484 03.06.13 23:40 Сейчас в теме
(11) pumbaE, подписываюсь под каждым словом. Но думаю, что тестов к типовым мы так и не дождемся. И, кстати, даже "Здесь был Вася", к сожалению, не все пишут.
13. _also 484 03.06.13 23:42 Сейчас в теме
(11) pumbaE, Жень, а не тестировал работу с хранилищем в 8.3. 1С там заявляла какие-то ништяки. Мол работать будет сравнение быстрее?
14. pumbaE 03.06.13 23:49 Сейчас в теме
(13) пока нет, дети заболели, нет времени. По тому что видел, для себя кардинального ничего не вынес. Пока вижу структуру хранилища похожую на git(но могу и ошибаться, но тут трудно что-либо новое придумать как со справочником "Номенклатура"). Скорость по сравнению с хранилищем старым действительно быстрее. По сравнению с аналогичной историей экспортированной в git хранилище еще не тестировал.
15. _also 484 03.06.13 23:52 Сейчас в теме
(14) pumbaE, я понял. Надо что-то придумывать с ролями и частичной выгрузкой в xml 8.3 и переходить на git...
27. omut 07.08.14 22:56 Сейчас в теме
(9) speshuric, полностью поддерживаю. Сам работаю точно по такой же схеме :)
Отдельно по запуску (пароли, пароли, пароли...) У кого нет снегопата: напишите батник с параметрами запуска и сразу попадете в конфигуратор под нужным пользователем в нужную базу и подключением к хранилищу. Если баз много, то файлов будет тоже много. Но это уже, что называется, на любителя. На всякий случай, если кто не знает, пример строки в батнике такой:
"C:\Program Files (x86)\1cv82\ВАША_ВЕРСИЯ_ПЛАТФОРМЫ\bin\1cv8.exe" DESIGNER /S СЕРВЕР_1С/ИМЯ_БД_1С /NИМЯ_ПОЛЬЗОВАТЕЛЯ_1С /PПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_1С /ConfigurationRepositoryNИМЯ_ПОЛЬЗОВАТЕЛЯ_ХРАЛИНИЩА /ConfigurationRepositoryPПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_ХРАНИЛИЩА (для клиент-серверной БД, если файловая база, то вместо /S ставим /F и дальше папку БД вместо сервера и имени БД)
29. Stas-ch 35 18.04.16 11:07 Сейчас в теме
(27) omut,
а зачем батники? Можно ведь все прописать сразу в параметрах запуска 1С. Из минусов - надо прописывать у всех, кто работает с базой (копи-паст рулит), зато нет кучи батников.
18. Kutuzov 736 04.06.13 08:12 Сейчас в теме
Еще хотелось бы подробную инструкцию по настройке подключения к хранилищу через интернет.
19. SPID 04.06.13 09:04 Сейчас в теме
По поводу "Захватил корень - добавил объект - поместил корень - захватил объект и дальше его разрабатываеш" тоже кроется подвох, если этот объект регистр - нужно не забыть добавить хоть одно измерение и назначить регистратор, если он необходим. Если поместить пустой регистр в хранилище, то для разработчика получившего конфигурацию с хранилища ждет сюрприз - он не сможет обновить конфигурацию БД, конфигуратор будет "ругаться" на этот регистр без регистратора и/или без измерений.
zqzq; romankoav; zuxelzz; vasiliy_b; +4 Ответить
20. _also 484 04.06.13 09:11 Сейчас в теме
(19) SPID, согласен. Вообще лучше все новые объекты, в том числе с реквизитами за один раз добавлять.
21. xzorkiix 34 05.06.13 11:07 Сейчас в теме
текст читаешь, приговаривая "конечно", "это же логично". Но всё равно полезно.

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

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

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

Имхо, на инфостарт-евенте скорее такого простого доклада ожидал, а поверх какие плюшки появляются при внедрении иных продуктов, технологий, методологий.
22. pumbaE 05.06.13 11:37 Сейчас в теме
(21) xzorkiix, не ставил себе целью описания работы с хранилищем. Рассказывать банальные вещи не очень хочется ни мне и вам их слушать тоже думаю не сильно охота.

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


p.s.: Ben Collins-Sussman: Итак есть два "класса" программистов-разработчиков, назовем их "20%" и "80%", основная движущая сила индуструии программного обеспечения - это "80%"-ные парни... Их знаний в точности достаточно, что бы сделать свою работу, затем пойти домой и забыть о комьютерах...
Жутка правда №1 - Основной объем...ПО - создается вышеупомянутыми "80%" программистов.
Жуткая правда №2 - Большинство "альфа - гиков" забывают "жуткую правду №1" .

Вышеупомянутым программистам вообще трудно использовать контроль версий, а вы собираетесь объяснять им разницу между "pull" и "update"...

Ben Collins-Sussman - автор svn.
_also; vikad; +2 Ответить
23. laduk 15 05.06.13 13:01 Сейчас в теме
Статья ни о чем, да еще и с неадекватными советами типа: "имя пользователя по имени базы и одинаковые пароли" - по моему полнейший бред;
"Рабочая база автоматически обновляется из хранилища" - да за такое руки поотрывать мало
24. _also 484 05.06.13 13:36 Сейчас в теме
(23) laduk, я рад, что Вам понравилось )
25. zqzq 23 05.06.13 16:56 Сейчас в теме
имя пользователя по имени базы и одинаковые пароли

ИМХО лучше на каждого программиста своего пользователя (с правами захвата) + админа хранилища + юзера с правами только на чтение для обновления рабочей из хранилища (лучше заходить с одного сервера). Тогда и нормальный отчет по истории работы с хранилищем будет. Естественно, для сложных случаев лучше рабочую обновлять поставками/объединением.
26. cdover 07.08.14 18:20 Сейчас в теме
всё по полочкам. Спасибо!
28. Templ 15.04.15 11:35 Сейчас в теме
Из-за чего может быть. Внесли изменения из хранлища в основную базу. И оказалось что в рабочую базу затянулось старая версия изменений.
30. Stas-ch 35 18.04.16 11:10 Сейчас в теме
а вот никто не знает как в случае копирования базы с изменениями, не внесенными в хранилище, перенести информацию о подключении к хранилище в эту новую базу?
т.е. средствами SQL скопировали базу, старую убили (или пока еще нет, но скоро убьют). Захожу в новую базу а информации о подключении ее к хранилищу нет - при попытке подключения к хранилищу вся информация замещается данными хранилища. Приходится выгружать через конфигуратор все изменения и закачивать их в новую базу. Муторно. Может есть способ проще? Поделитесь.
31. Дмитрий74Чел 234 08.10.18 09:14 Сейчас в теме
(30)Официально способа нет. Вы неправильно понимаете суть регитстрации базы в хранилище.
Информация о подключении харнится на 2х сторонах: и в базе (к какому хранилищу подключена, скорее всего, просто путь к хранилищу), и в хранилище (какие базы подключены, скорее всего просто в виде "сервер-база").
Таким образом, при копировании базы, в ней остается информация о хранилище, поэтому и выходит окно с предложением ввести логин и пароль. Но логин и пароль (правильные) не примет само хранилище, т.к. путь к базе не совпадает с сохраненным в хранилище.

Цитата с ИТС:
https://its.1c.ru/db/v8doc#content:82:1:issogl2_28.1.2.подключениекхранилищу
Если имя пользователя зарегистрировано и для этого пользователя информационная база еще не была подключена к хранилищу конфигураций, то производится подключение и устанавливается связь: в хранилище по данному пользователю записывается информация о конфигурации и ее месте расположения.

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

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

Если для данного пользователя в данный момент времени нет открытой информационной базы, но данные о месте расположения не совпадают с данными о связи (конфигурация расположена в другом каталоге, или подключение производится с другого рабочего места), то конфигуратор выводит сообщение: Для данного пользователя уже имеется конфигурация, связанная с данным хранилищем конфигурации. Продолжить? Если нажать кнопку Да, то происходит установка нового подключения, текущая конфигурация заменяется конфигурацией из хранилища и устанавливается новая связь текущей конфигурации с хранилищем для данного пользователя.
32. romankoav 4 31.05.19 12:37 Сейчас в теме
Все внимательно прочел, но так и не увидел веских доводов (кроме странных страхов) почему не стоит не подключать рабочую базу к хранилищу. Так почему же?
33. CratosX 112 04.12.19 11:59 Сейчас в теме
(32) Аналогично. Используем на мелких доработках, плюсов от этого больше, чем минусов (для оперативных исправлений нужно захватывать объект, а он может быть захвачен кем-то). На крупных же конфигураций и/или с большой командой разработчиков хорошо описано в (9)

Кстати, раньше я как-то указывал метки к версиям хранилища, а сейчас не нашёл, как это сделать, подскажет кто?
Оставьте свое сообщение