Как повредить базу 1с

Обновлено: 08.01.2025

Ранее в нескольких хардкорных публикациях мы говорили о работе с журналом регистрации нестандартными способами:

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

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

Полный рандом

Все персонажи являются вымышленными. Любое совпадение с реальными событиями и людьми случайно.

Трэш и угар

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

Мой личный номер

Теплым летним днем на линию поддержки прилетает ошибка при записи заказа клиента.

Начинается расследование. Выясняется, что кто-то вручную изменил номер документа заказа клиента на максимальный, тем самым остановив ввод новых документов. А значит и продаж (хотя может и нет). А значит, что будут последствия и не малые. Конечно, пользователи могут найти и обходной путь, особенно если это заказ клиента. Но если бы это была реализация или другой более критичный документ? Проблемы были бы в любом случае, но масштаб, конечно всегда разный.

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

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

Выводы:

Сломать нумерацию в документах 1С просто, если разрешено ручное изменение номера. А в большинстве случаев это именно так.
Аналогичные проблемы распространяются на все объектные сущности: документы, справочники и т.д.
Необходимо серьезно подходить к вопросу ручного изменения номеров и кодов объектов, даже если таких проблем у Вас еще не возникало.
Будьте бдительны, возможно такая бомба уже есть в Вашей системе. Ведь она есть во многих типовых и отраслевых решениях.

Проблема может быть решена запретом редактирования номеров и кодов объектов. Как это сделать именно в Вашей конфигурации зависит от многих факторов, так что универсального ответа давать не буду. Можно посмотреть готовые решения здесь на Инфостарт, инновационного здесь ничего нет.

Отфильтруй мне это

Представьте, с теми же заказами клиентов работает менеджер, у которого свои собственные задачи. Например, руководство поставило ему задачу найти все заказы со статусом "Ожидается согласование", у которых сумма заказа в диапазоне от 10 тыс. руб. до 50 тыс. рублей или более 500 тысяч. Не важно почему такие условия, просто нужно и все тут. При этом попросили исключить нескольких клиентов из этого списка. Исполнительный менеджер идет в список заказов, далее "Еще -> Настроить список". Тут задает условия точно так, как нужно.

Если количество заказов не большое, то все будет хорошо и система обработает такой запрос. Но если их сотни тысяч, миллионы? Ну, Вы понимаете о чем я? ;-)

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

Еще интересный момент - это автоматическое сохранение пользовательских настроек в динамических списках. По умолчанию в новых версиях платформы эта опция включена. В конфигураторе она указывается в свойствах динамического списка.

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

В обычных ситуациях сотрудник, который столкнулся с таким поведением, старается таких отборов больше не ставит и даже не пишет в службу ИТ для исправления ситуации (у них и так много проблем :)). В других же случаях функционал используют далее не смотря на медленную работу, тем создавая другие проблемы производительности.

Выводы:

Динамические списки с произвольными отборами - это тоже медленные бомбы как и нумерация.
Чем больше возможностей, тем больше ответственность. Но пользователи программы не догадываются о ней.
Простой вариант решения - отключить возможность гибких отборов через "Настроить список" и через Ctrl+F. Добавить ограниченный набор отборов на форму для основных вариантов поиска. Но это нужно постараться сделать, потребуются доработки конфигурации.
Сложный вариант - полностью изменить логику поиска в списках. Можно использовать стандартный полнотекстовый поиск или реализовать свой внешний сервис. Но это другая история.

Динамические списки периодически могут становиться причиной падений и замедления работы. По опыту именно запросы в списках чаще всего попадают в ТОП по нагрузке сервера СУБД, даже обгоняя тяжёлые отчеты. Да, именно так. Ведь отчет запускают один раз, а динамический список используют постоянно. А если вспомнить отборы "По вхождению строки", то.

Отчет на все времена

Еще один вариант шикарного использования динамического списка - это замена для отчетов. Например, сотруднику понадобилось проанализировать заказы клиентов за последних два года в разных разрезах. Готовых отчетов в системе не нашлось, а просить у разработчиков новый отчет дело долгое, да еще и тестировать придется. А там еще и аналитика надо найти. Есть ведь путь проще!

Решение простое - в динамический список добавить нужные колонки через "Изменить форму", поставить нужные фильтры через "Еще -> Настроить список" и выгрузить весь сформированный список в Excel, предварительно нажав Ctrl+A. Profit!

Добавляем поля от ссылки через "Еще -> Изменить форму" от ссылки (если такое доступно, конечно).

Далее нажимаем Ctrl+A (выделяя все записи) и выгружаем все что подготовили.

Что может пойти не так? Да очень многое:

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

Выводы:

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

Как умеем, так и выгружаем :)

Мой справочник, мой!

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

Например, вот сформированная печатная форма заказа клиента.

Тут выяснилось, что "ЗАО "Торговый дом Комплексный" - не то что нужно для заказа клиента. Но у пользователя были закрыты права на редактирование содержимого печатной формы, а вот, о чудо, изменять справочник "Организации" было разрешено. Ответ очевиден! Нужно изменить наименование организации.

После этого в печатной форме все сформируется как надо.

Все было бы хорошо, но:

Это же многопользовательская система. Все кто формировал печатные формы после этой манипуляции тоже получат это название. Всех ли оно устроит? Будет ли кто-то опять переименовывать справочник?
Даже если исходное наименование вернут обратно, ошибок и вопросов в системе за короткий промежуток времени может накопиться порядочно.
Также могу сломаться большое число "костылей", если Вы их практикуете в работе. Речь идет о поиске по наименованию, синхронизации организаций в конвертации по наименованию и прочее.
Риск нарушения работы будет присутствовать постоянно. А если пользователи будут менять не наименование, а ИНН, КПП, платежные реквизиты?

В общем, права доступа вещь серьезная.

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

Нужно больше сеансов

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

Есть тяжелые операции, которые проще запускать сразу в нескольких сеансах, чтобы ускорить работу с программой:
1. Тяжелые отчеты, которые не выполняются в фоновом режиме.
2. Проведение некоторых документов занимает очень много времени.
3. Поиск в динамических списках не отличается быстрым откликом. Почему бы тоже не запустить несколько сеансов.
К чему это может привести:
- Дополнительная нагрузка на сервер 1С и СУБД, если тяжелый отчет запускается многократно в разных сеансах. Даже если отчет выполнится, и пользователь его просто не дождался, то все равно излишняя нагрузка будет присутствовать.
- Бесконтрольное выполнение тяжелых алгоритмов в информационной базе.
- Излишнее использование лицензий при определенной конфигурации сервера и настроек лицензирования.
- Ошибки прикладного решения, которые может никогда бы и не всплыли в обычной работе. Все ли в порядке с установкой блокировок при параллельной работе сеансов / пользователей?
Иногда решением может быть контроль запуска нескольких сеансов одним пользователем, но такой подход не всегда рабочий. Нужно разбираться с конкретной ситуацией.

Вывод: запуск нескольких сеансов одним пользователем удобный подход, но с некоторыми рисками.

А как обстоят дела у Вас?

Перепровести все!

Еще немного про динамический список. Может случиться так, что пользователь через Ctrl+A выделит большое количество документов и нажмет "Провести" (или отмена проведения, или пометка на удаление - не важно). Что в этом случае будет? Правильно - на сервере начнется настоящее "веселье", ведь эта операция явно не самая легкая по использованию ресурсов. А если были выделены все документы за месяц?

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

Какое может быть решение по запрету таких действий? Тут тоже все зависит от контекста, свою систему Вы знаете лучше. Но можно предложить:
1. Запрет проведения документов предыдущих дней в зависимости от прав доступа.
2. Сделать мониторинг массовых операций пользователями. В случае появления любой большой операции отправлять уведомление администратору.
3. Организационные решения вопроса :)
В любом случае, такое поведение возможно во всех решения на платформе 1С. Лишь в некоторых мне встречались защиты от подобных действий.

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

Я скачал с Инфостарта!

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

Повезет, если права доступа все же остановят работу неизвестного инструмента. Но всегда ли такое будет? А сгенерированные ошибки в данных могут "всплыть" только спустя пару месяцев.

Тут можно сразу и закончить.

Вывод: закрывайте доступ на открытие внешних отчетов и обработок из файлов. Альтернативы просто нет.

Я у мамы программист

Еще один хардкорный случай - это когда с правами доступа совсем беда, а главный бухгалтер - бывший программист или консультант. Даже если с правами все ОК, то для такого высокопоставленного сотрудника они могут быть полные. Что может пойти не так? Правильно! Сотрудник для решения своих проблем зайдет в конфигуратор и запрограммирует все что ему нужно. Или выгонит всех пользователей по середине рабочего дня и начнет формировать выгрузку DT'шника, чтобы с ней работать отдельно. Что Вы говорите, база 1 ТБ? Ну на выходных запущу.

Какое здесь решение? Даже говорить об этом не хочется :)

Вне закона

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

Решается это построением продуманных прав доступа всем пользователям системы. Добавить тут нечего.

Вы в безопасности

Конечно, часть информации выше имеет шуточный характер. Но в шутке есть только доля шутки. Часть случаев, но в некотором измененном виде, встречал на практике. Иногда хотелось смеяться, иногда плакать.

Поделитесь своими историями и забавными случаями в работе. Поделитесь щепоткой трэша и угара!

Другие ссылки
- В целях цензуры и здравого смысла другие ссылки не стал добавлять, но Вы можете оставить их в комментариях.
Авторские разработки

Транслятор запросов 1С в SQL - инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.

Просмотр и анализ структуры базы данных (отчет на СКД) - отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.

Просмотр и анализ журнала регистрации (отчет на СКД) - отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации.

История работы пользователей (отчет на СКД) - отчет для просмотра истории работы пользователей (СКД, просмотр для любого пользователя).

Экспорт журнала регистрации. Набор инструментов (приложения + исходный код) - набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux. Готовые приложения и исходный код.

Путеводитель по истории релизов - отчет по истории выпуска релизов продуктов фирмы "1С" и анализа информации по обновлениям.
Анализ производительности APDEX (бесплатный) - отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

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

Пакетная выгрузка / загрузка внешних отчетов и обработок - пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.

Мастер полнотекстового поиска - набор инструментов для работы с полнотекстовым индексом платформы 1С. Стандартные и расширенные возможности.

Командный интерпретатор для 1С - инструмент для выполнения команд CMD / PowerShell из 1С

skype: live:di-sem

@programmist_1C

Перед тем как начать исправлять базу обязательно сделайте резервную копию!

1. Через конфигуратор

Тестирование и исправление информационной базы в 1С 8.2 и 8.3.
Нужно войти в конфигуратор администрирование - тестирование и исправление.

2. Утилита chdbfl.exe

Если в конфигуратор войти нет возможности можно воспользоваться утилитой chdbfl.exe. Ее скачивать не нужно, она находится в папке, где установлена 1С.

Например в C:\Program Files (x86)\1cv8\8.3.10.2561\bin\chdbfl.exe , где 8.3.10.2561 - номер релиза платформы.

У меня утилита chdbfl.exe находится тут

Нужно ее запустить, выбрать файл 1Cv8.1CD в папке базы 1с, поставить галочку "Исправлять обнаруженные ошибки" и запустить.

3. Очистить кэш (более подробно смотреть тут) .

Бывают такие глюки\сбои которые очень хорошо исправляются очисткой кэша.

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

Способ очень простой.

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

И сделать так:

1 Выбрать в списке нужную базу

2 Удалить ее из списка, сама база не удалится. Главное запомните или запишите где она лежит.

3 Заново ее пропишите.

Сейчас у одного из моих клиентов ситуация в которой не помог ни один из этих способов.

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

База файловая, находится на вирт машине, 1с без сервера запускается с другой вирт. машины.

Возможно 1с просто не хватает ресурсов.

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

Тогда буду перенастраивать.

Скачал базу себе, тестировал ее весь день - ни одной ошибки.

Узнал что ресурсов на компьютере клиента достаточно.

Решено. Проблема была в платформе.

Переустановка платформы и удаление старых версий полностью решило проблему. :)

Доброго времени. Скажите пожалуйста каким образом можно обезопасить базы 1С да и другие данные от кражи сотрудниками фирмы? Заранее благодарен.

каким образом можно обезопасить базы 1С да и другие данные от кражи сотрудниками

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

Отключить все порты ввода/вывода (usb, cdrom, lpt,serial, интернет) перейти на sql.
И/или давать достуа только удаленно по rdp/vmware view
Но если сильно захочиться то и монитор по фоткают или в блокнотик перепишут

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

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

Алексей Константинов: Обычно, если говорят сервер, то имеют ввиду именно сервер, а не десктоп ;)

Алексей Константинов: Возможно про разные вещи говорим. Я имею ввиду, что пользователь 1С коннектится к серверу 1С, который, в свою очередь, коннектится к СУБД.
То есть, чтобы подключиться к SQL базе надо знать логин\пароль от самой базы, а не пользователя для входа в 1С.
Извиняюсь за долгий ответ.

Надо ввести договор, в котором прописать жесткую ответственность за каждый файл, который будет доступен пользователю. Прописать штрафы размером в оклад за 10 лет. И в суд подавать показательно.
Если нужно базу спионерить, то и Пентагон не в силах защититься от инсайдеров/аутсайдеров.
Вообще каждый сотр должен работать ТОЛЬКО в своей области данных, еще дополнительная "защитка" в виде конкуренции по отделам организации. Надо смотреть на структуру фирмы и тп.
И по-максимуму логировать все действия пользователя, чтобы было что предъявить в иске если что.

Сразу что пришло в голову:
1) Ограничить доступ к базам 1С физически и на уровне AD или пользователей
2) Перейти на клиент-серверную версию
3) Отобрать у всех полные права и оставить только администратору
4) Ограничить использование flash-накопителей и DVD-RW через политики безопасности Windows
5) Ограничить использование интернета и мониторить использование WEB-ресурсов. Установить прокси-сервер.
Есть еще дополнительные меры, так что лучше обратиться к специалисту по информационной безопасности.

Механизм РИБ — механизм распределенных информационных баз - это когда у вас есть главная база и подчиненная(ые). Главная база может быть только одна, подчиненных может быть много. Каждая подчиненная база может иметь свои подчиненные базы, для которых она будет главной.

Вот посмотрим на картинку из первой ссылки по запросу в Яндексе:

РИБ используется для обмена данными. Причем не только теми данными, с которыми работает пользователь, но и данными изменения конфигурации. То есть РИБ позволяет передавать изменения конфигурации. Но изменить конфигурацию можно только в главной базе!

Визуализируем:

У нас большая компания и много филиалов. Есть доработанная УНФ, которую мы гордо называем УБФ(Управление Большой Фирмой). Но мы решили, что хватит терпеть то, что все филиалы имеют доступ к документам всех филиалов и каждому филиалу решили сделать отдельную базу, которую синхронизировать с нашей основной базой для передачи данных. Что ж, можно. Сделали.

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

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

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

Как создать подчиненную базу, на пальцах:

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

1) Сначала проделаем шаги, как при настройке обычной синхронизации:

2) . поставим галочку, нажмем.

4) тут ознакомимся с описанием. Я выберу обычную настройку, но если бы мы следовали примеру выше, то нужно было бы выбрать "с фильтром" и там одним кликом выбрать нужный филиал.

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

7) в общем случае, тут ничего не надо нажимать, кроме "Записать и закрыть".

8) А вот теперь создаем нашу новую подчиненную базу:

9) указываем место, куда ее покладем.

10) Зайдем в нашу новую подчиненную базу и закончим настройки синхронизации(синхронизация уже создалась, так как использовали РИБ, но нужно указать каталог для обмена выбрав "Настройки подключения")

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

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

В общем-то ВСЕ.

Подчиненная база создана!

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

Вот что-то изменили в основной базе:

нам нужно перенести изменения в базы-дочки.

Для этого запускаем главную базу в режиме 1С:Предприятие, то есть в пользовательском интерфейсе, заходим в настройки синхронизации, жмем выделенную кнопку:

После того, как синхронизация закончится, заходим в базу дочку и так же жмем "Синхронизировать", база загрузит данные и напишет:

После нажатия на Далее база закроется и начнет устанавливать обновления.

Когда обновы установятся, база начнет запускаться и сообщит нам следующее:

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

Откроем конфигурацию и вот что увидим

Нажмем на "Обновить конфигурацию базы данных".

Увидим список изменений, которые прилетели с обновлениями:

И вот эти обновления появились в подчиненной базе.

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

Несколько правил:

1) Все узлы, кроме одного, должны иметь по одному главному узлу и один узел не будет иметь главного узла - это корневой узел.

2) Конфигурация может быть изменена только в узле, не имеющем главного узла (то есть в корневом).

3) Изменения конфигурации будут передаваться от главного к подчиненным узлам.

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

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

А теперь то, ради чего все писалось.

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

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

1) Заходим в свойства ярлыка запуска окна 1С:Предприятие:

2) В поле "Объект" дописываем:

DESIGNER /F"Путь до базы" /N"Имя Пользователя в базе" /P"Пароль пользователя" /ResetMasterNode

Читайте также: