Как разрушить базу 1с
Шаблон создаётся с помощью установочного комплекта (дистрибутива). Такой дистрибутив есть на диске, идущем в комплекте с программой. Свежий можно получить у обслуживающего франча или в самой 1С, на линии консультаций.
Как удалить все документы (очистить базу) в 1С 8.3?
Как обнулить 1с
Часто возникает необходимость создать ещё одну базу данных. При этом, нужна база данных такая же как у вас уже есть (бухгалтерия, торговля и т.п.) только пустая (без данных, но с полным функционалом). Условно, создание новой базы можно разбить на несколько вариантов:
- Создание базы данных из шаблона.
- Создание базы данных из конфигурационного файла (с расширением *.cf).
- Создание пустой базы данных, используя другую базу данных.
Рассмотрим несколько случаев в которых можно это сделать.
Создание базы данных из шаблона
Этот способ самый простой. Программа 1С все делает за пользователя. Опишем его предельно кратко и ясно:
- Открываем список Ваших информационных баз (запускаем ярлык 1С).
- Нажимаем кнопку "Добавить".
- Оставляем переключатель в положении "Создание новой информационной базы", нажимаем "Далее".
- Указываем, что хотим создать базу из шаблона. Разворачиваем дерево с доступными шаблонами и выбираем нужный. Шаблон определяет тип базы: Бухгалтерия предприятия, Управление Торговлей, Зарплата и т.п. Нажимаем "Далее".
- Указываем как база данных будет называться в списке, нажимаем "Далее". *
- Указываем каталог, в который хотим поместить базу данных, или оставляем по-умолчанию. ** Нажимаем "Далее".
- Оставляем переключатели в положении "Выбирать автоматически" и нажимаем "Готово".
* — в данной статье рассматривается самый простой (файл-серверный) вариант создания базы. При создании базы данных на сервере 1С:Предприятие в режиме "клиент-сервер", лучше обратиться к специалисту. Поэтому в п. 5 мы оставляем переключатель в положении "на данном компьютере или в локальной сети".
** — Конечно, можно оставить все по-умолчанию, однако, не очень надежно хранить вашу базу данных в папке "Мои документы" или в целом на системном диске (диск C:\). Если есть такая возможность, рекомендуем создать папку специально для хранения Вашей информационной базы не на диске C:\. В этом случае путь может выглядеть, например, так: "E:\Базы_1С\Бухгалтерия_Ромашка\".
Рассмотренный способ очень прост, однако имеет ряд недостатков. Если не обновлять шаблоны конфигураций постоянно, то по прошествии нескольких периодов, таким способом можно будет создать только устаревшую версию базы данных. Либо шаблоны конфигураций могут просто отсутствовать. Поэтому мы рекомендуем воспользоваться Вам способом, рассмотренным в следующем разделе.
Создание базы данных из файла конфигурации (*.cf)
Файл конфигурации — это файл, определяющий, какой будет база данных: Бухгалтерия предприятия, Управление торговлей, Зарплата и Управление персоналом и т.д. Можно сказать, это "рыба" будущей базы данных. Сразу стоит сказать, что если у Вас нет файла конфигурации, его можно легко выгрузить из другой базы данных. Об этом подробно будет написано в последнем разделе этой статьи.
Итак, прежде всего нам нужно создать папку, в которой мы будем хранить нашу новую базу данных.
- Создаете в любом месте на компьютере пустую папку. Хорошо продумайте название и место расположения папки. Желательно, чтобы это был не системный диск (не диск C:\).
- В списке информационных баз (даже если там пока нет ни одной базы) нажмите на кнопку "Добавить".
- Отвечая на вопросы помощника добавления новой базы, пройдите все пункты:
- Выберите пункт "Создание новой базы", нажмите "Далее".
- Далее переключите "точку" на пункт "Создание информационной базы без конфигурации для разработки. ". Нажмите далее.
- Укажите как база будет называться. Нажмите далее.
- Нажмите на кнопку выбора ". " и укажите папку, которую Вы создали в п. 1. Причем в диалоге выбора, который откроется, необходимо войти в нужную папку и только потом нажать на кнопку "Открыть". В результате в поле "путь" должен прописаться путь к указанной папке.
- Нажимаете кнопку "Далее".
- Оставляя все по-умолчанию, нажимаете на кнопку "Готово".
- Итак, мы создали пустую базу без конфигурации в нашей папке.
Сейчас созданная база не имеет ни данных, ни какой-либо функциональности. Т.е. она бесполезна. 🙂 Чтобы эта функциональность у базы появилась, нужно загрузить в неё Конфигурационный файл (с расширением *.cf). Сделать это тоже очень просто:
- Заходите в созданную пустую базу в режиме "конфигуратор": для этого в списке информационных баз становитесь на нужную и нажимаете на кнопку "Конфигуратор".
- В открывшемся окне выбираете меню "Конфигурация" — "Открыть конфигурацию" (Если пункт меню недоступен, значит конфигурация уже открыта).
- Далее выбираете меню "Конфигурация" — "Загрузить конфигурацию из файла" и выбираете файл с расширением *.cf
- Далее на все вопросы отвечаете положительно, на все соглашаетесь. Готово!
После того как закончатся все процедуры загрузки и сохранения, запускайте базу данных в обычном режиме и начинайте работу. Таким образом мы сделали пустую базу 1С 8 без данных, но с полной функциональностью.
Создание базы данных, используя другую базу данных
Если перед Вами стоит задача создать базу данных такую же, как у Вас уже есть, но пустую. Вам понадобится Конфигурационный файл (с расширением *.cf), выгруженный из имеющейся базы. Сделать это очень просто. Для этого:
- Заходите в имеющуюся базу в режиме "конфигуратор": для этого в списке информационных баз становитесь на нужную и нажимаете на кнопку "Конфигуратор".
- В открывшемся окне выбираете меню "Конфигурация" — "Открыть конфигурацию" (Если пункт меню недоступен, значит конфигурация уже открыта).
- Далее выбираете пункт меню "Конфигурация" — "Сохранить конфигурацию в файл".
- Выбираете место, куда будет сохранен файл конфигурации и задаете ему имя. Например, переходите на рабочий стол и указываете "Конфигурация_Бухгалтерии.cf". Нажимаете "Сохранить".
* Очистка информационной базы от данных
На практике часто возникает необходимость очистить какую-либо базу от данных полностью. Пусть формулировка задачи не вводит Вас в заблуждение! В этом случае просто создайте новую пустую базу на основании существующей, как описано в предыдущих разделах, а старую можете удалить или поместить в архив.
Ранее в нескольких хардкорных публикациях мы говорили о работе с журналом регистрации нестандартными способами:
Настало время поговорить о чем-нибудь простом, приземленном. Поговорим о теме, актуальной для всех. Как разработчикам и администраторам, так и простым пользователям. О том, как случайными (или не всегда случайными) действиями можно уронить информационную систему на платформе 1С. Причем это могут сделать почти все, кто работает с ней, не только божественные администраторы и разработчики.
Даже простой пользователь в силах создать серьезные проблемы в ее работе самыми обычными рабочими действиями. В лучшем случае работа будет исправлена в течении короткого промежутка времени, в худшем может потребоваться вмешательство эксперта для анализа и исправления ситуации. А иногда даже потребуется реализация большого проекта.
Полный рандом
Все персонажи являются вымышленными. Любое совпадение с реальными событиями и людьми случайно.
Трэш и угар
Практически все случаи, которые будут описаны далее, не являются проблемами самой платформы 1С, а лишь являются результатом непродуманной разработки конфигураций, решений на ее основе, ошибками внедрения, сделанными настройками и так далее. Но давайте уже к делу :)
Мой личный номер
Теплым летним днем на линию поддержки прилетает ошибка при записи заказа клиента.
Начинается расследование. Выясняется, что кто-то вручную изменил номер документа заказа клиента на максимальный, тем самым остановив ввод новых документов. А значит и продаж (хотя может и нет). А значит, что будут последствия и не малые. Конечно, пользователи могут найти и обходной путь, особенно если это заказ клиента. Но если бы это была реализация или другой более критичный документ? Проблемы были бы в любом случае, но масштаб, конечно всегда разный.
Даже если героя найдут по данным журнала регистрации или полю "Ответственный" в документе, то это ничего не изменит. Кто-то другой может также изменить номер в будущем и не только в заказах клиента. Да и текущую проблему нужно решать. Перед редактированием номера появляется предупреждение, но кто его читает!
Ситуация может ещё более плачевной, если вручную номер изменят не сразу на максимальный, а близкий к максимальному номер. Тогда ошибка появится через некоторое время. А если старые документы будут уже в закрытом периоде, то и перенумеровать их для исправления ошибки уже будет не так просто (тут может влиять еще периодичность нумерации, но смысл думаю понятен).
Выводы:
- Сломать нумерацию в документах 1С просто, если разрешено ручное изменение номера. А в большинстве случаев это именно так.
- Аналогичные проблемы распространяются на все объектные сущности: документы, справочники и т.д.
- Необходимо серьезно подходить к вопросу ручного изменения номеров и кодов объектов, даже если таких проблем у Вас еще не возникало.
- Будьте бдительны, возможно такая бомба уже есть в Вашей системе. Ведь она есть во многих типовых и отраслевых решениях.
Проблема может быть решена запретом редактирования номеров и кодов объектов. Как это сделать именно в Вашей конфигурации зависит от многих факторов, так что универсального ответа давать не буду. Можно посмотреть готовые решения здесь на Инфостарт, инновационного здесь ничего нет.
Отфильтруй мне это
Представьте, с теми же заказами клиентов работает менеджер, у которого свои собственные задачи. Например, руководство поставило ему задачу найти все заказы со статусом "Ожидается согласование", у которых сумма заказа в диапазоне от 10 тыс. руб. до 50 тыс. рублей или более 500 тысяч. Не важно почему такие условия, просто нужно и все тут. При этом попросили исключить нескольких клиентов из этого списка. Исполнительный менеджер идет в список заказов, далее "Еще -> Настроить список". Тут задает условия точно так, как нужно.
Если количество заказов не большое, то все будет хорошо и система обработает такой запрос. Но если их сотни тысяч, миллионы? Ну, Вы понимаете о чем я? ;-)
Подобный отбор в списке еще не самый изощренный с которым можно столкнуться. В результате применения подобных отборов на большой базе могут появиться серьезные тормоза не только в работе сеанса этого пользователя, но и всей информационной базы. Ситуация может усложниться еще и тем, что они могут быть установлены несколькими сотрудниками. Что на это скажет Ваш сервер баз данных? Правильно, ему может быть очень нехорошо и всеобщие "тормоза" в системе в таких случаях не редкость.
Еще интересный момент - это автоматическое сохранение пользовательских настроек в динамических списках. По умолчанию в новых версиях платформы эта опция включена. В конфигураторе она указывается в свойствах динамического списка.
Если пользователь поставил "тяжелый" отбор и у него "подвисла" программа на длительное время, и он дождался завершения операции, то при следующем открытии эти отборы будут восстановлены. Это значит, что подвисание появится теперь уже при открытии и коллега будет сильно удивлен, почему список стал открываться так долго.
В обычных ситуациях сотрудник, который столкнулся с таким поведением, старается таких отборов больше не ставит и даже не пишет в службу ИТ для исправления ситуации (у них и так много проблем :)). В других же случаях функционал используют далее не смотря на медленную работу, тем создавая другие проблемы производительности.
Выводы:
- Динамические списки с произвольными отборами - это тоже медленные бомбы как и нумерация.
- Чем больше возможностей, тем больше ответственность. Но пользователи программы не догадываются о ней.
- Простой вариант решения - отключить возможность гибких отборов через "Настроить список" и через Ctrl+F. Добавить ограниченный набор отборов на форму для основных вариантов поиска. Но это нужно постараться сделать, потребуются доработки конфигурации.
- Сложный вариант - полностью изменить логику поиска в списках. Можно использовать стандартный полнотекстовый поиск или реализовать свой внешний сервис. Но это другая история.
Динамические списки периодически могут становиться причиной падений и замедления работы. По опыту именно запросы в списках чаще всего попадают в ТОП по нагрузке сервера СУБД, даже обгоняя тяжёлые отчеты. Да, именно так. Ведь отчет запускают один раз, а динамический список используют постоянно. А если вспомнить отборы "По вхождению строки", то.
Отчет на все времена
Еще один вариант шикарного использования динамического списка - это замена для отчетов. Например, сотруднику понадобилось проанализировать заказы клиентов за последних два года в разных разрезах. Готовых отчетов в системе не нашлось, а просить у разработчиков новый отчет дело долгое, да еще и тестировать придется. А там еще и аналитика надо найти. Есть ведь путь проще!
Решение простое - в динамический список добавить нужные колонки через "Изменить форму", поставить нужные фильтры через "Еще -> Настроить список" и выгрузить весь сформированный список в Excel, предварительно нажав Ctrl+A. Profit!
Добавляем поля от ссылки через "Еще -> Изменить форму" от ссылки (если такое доступно, конечно).
Далее нажимаем Ctrl+A (выделяя все записи) и выгружаем все что подготовили.
Что может пойти не так? Да очень многое:
- При выделении записей в списке платформа выполнит огромное количество служебных запросов, особенно если записей в базе очень много.
- Если установлены "тяжелые" отборы как в предыдущем примере, то это может создать значительную нагрузку на сервер баз данных.
- Выгрузка списка в Excel может значительно увеличить размер сеансовых данных на сервере 1С. Вплоть до использования всего свободного пространства на диске.
- Подобная выгрузка может выполняться очень долго. В том числе и не завершиться никогда.
Выводы:
- Это еще одна пасхалка от динамических списков.
- Встретить подобное использование списков можно во многих компаниях. Многие разработчики даже не подозревают, что вытворяют их коллеги от бизнеса.
- Решить проблему можно либо запретом гибких настроек списков и отборов, либо реализацией выгрузки данных специализированными отчетами со строго ограниченными настройками.
Как умеем, так и выгружаем :)
Мой справочник, мой!
Еще забавный кейс. Сотрудник сформировал печатную форму, в шапке которой фигурирует организация. Все бы ничего, но ему название не понравилось и необходимо было поменять на более подходящее. В самой печатной форме прав на изменение содержимого не оказалось, но есть и другой путь! Изменить название организации в самой элементе справочника!
Например, вот сформированная печатная форма заказа клиента.
Тут выяснилось, что "ЗАО "Торговый дом Комплексный" - не то что нужно для заказа клиента. Но у пользователя были закрыты права на редактирование содержимого печатной формы, а вот, о чудо, изменять справочник "Организации" было разрешено. Ответ очевиден! Нужно изменить наименование организации.
После этого в печатной форме все сформируется как надо.
Все было бы хорошо, но:
- Это же многопользовательская система. Все кто формировал печатные формы после этой манипуляции тоже получат это название. Всех ли оно устроит? Будет ли кто-то опять переименовывать справочник?
- Даже если исходное наименование вернут обратно, ошибок и вопросов в системе за короткий промежуток времени может накопиться порядочно.
- Также могу сломаться большое число "костылей", если Вы их практикуете в работе. Речь идет о поиске по наименованию, синхронизации организаций в конвертации по наименованию и прочее.
- Риск нарушения работы будет присутствовать постоянно. А если пользователи будут менять не наименование, а ИНН, КПП, платежные реквизиты?
В общем, права доступа вещь серьезная.
Вывод: проверьте, нет ли таких "пасхалок" в Вашей системе. Только грамотная настройка прав доступа сможет от такого защитить.
Нужно больше сеансов
Еще одним особенным случаем является множественный запуск сеансов 1С одним пользователем. Причин может быть несколько:
- Есть тяжелые операции, которые проще запускать сразу в нескольких сеансах, чтобы ускорить работу с программой:
- Тяжелые отчеты, которые не выполняются в фоновом режиме.
- Проведение некоторых документов занимает очень много времени.
- Поиск в динамических списках не отличается быстрым откликом. Почему бы тоже не запустить несколько сеансов.
К чему это может привести:
- Дополнительная нагрузка на сервер 1С и СУБД, если тяжелый отчет запускается многократно в разных сеансах. Даже если отчет выполнится, и пользователь его просто не дождался, то все равно излишняя нагрузка будет присутствовать.
- Бесконтрольное выполнение тяжелых алгоритмов в информационной базе.
- Излишнее использование лицензий при определенной конфигурации сервера и настроек лицензирования.
- Ошибки прикладного решения, которые может никогда бы и не всплыли в обычной работе. Все ли в порядке с установкой блокировок при параллельной работе сеансов / пользователей?
Иногда решением может быть контроль запуска нескольких сеансов одним пользователем, но такой подход не всегда рабочий. Нужно разбираться с конкретной ситуацией.
Вывод: запуск нескольких сеансов одним пользователем удобный подход, но с некоторыми рисками.
А как обстоят дела у Вас?
Перепровести все!
Еще немного про динамический список. Может случиться так, что пользователь через Ctrl+A выделит большое количество документов и нажмет "Провести" (или отмена проведения, или пометка на удаление - не важно). Что в этом случае будет? Правильно - на сервере начнется настоящее "веселье", ведь эта операция явно не самая легкая по использованию ресурсов. А если были выделены все документы за месяц?
Замедление работы системы и появление таймаутов на блокировках - это только одна беда. Еще могут появиться расхождения в данных отчетов и прочие непредсказуемые последствия.
Какое может быть решение по запрету таких действий? Тут тоже все зависит от контекста, свою систему Вы знаете лучше. Но можно предложить:
- Запрет проведения документов предыдущих дней в зависимости от прав доступа.
- Сделать мониторинг массовых операций пользователями. В случае появления любой большой операции отправлять уведомление администратору.
- Организационные решения вопроса :)
В любом случае, такое поведение возможно во всех решения на платформе 1С. Лишь в некоторых мне встречались защиты от подобных действий.
Вывод: динамические списки вещь особая как и права доступа. Нужно внимательно относится к их возможностям.
Я скачал с Инфостарта!
В некоторых компаниях никто не беспокоится о том, что у пользователей программы есть доступ к открытию внешних отчетов и обработок из файлов. Это хорошо, доверие штука классная. Но что, если пользователь скачает, например, вот такую обработку и запустит, не предупредив доблестных воинов ИТ-отдела. Да любую другую обработку, которая может сделать самые непредсказуемых действий в руках пользователя.
Повезет, если права доступа все же остановят работу неизвестного инструмента. Но всегда ли такое будет? А сгенерированные ошибки в данных могут "всплыть" только спустя пару месяцев.
Тут можно сразу и закончить.
Вывод: закрывайте доступ на открытие внешних отчетов и обработок из файлов. Альтернативы просто нет.
Я у мамы программист
Еще один хардкорный случай - это когда с правами доступа совсем беда, а главный бухгалтер - бывший программист или консультант. Даже если с правами все ОК, то для такого высокопоставленного сотрудника они могут быть полные. Что может пойти не так? Правильно! Сотрудник для решения своих проблем зайдет в конфигуратор и запрограммирует все что ему нужно. Или выгонит всех пользователей по середине рабочего дня и начнет формировать выгрузку DT'шника, чтобы с ней работать отдельно. Что Вы говорите, база 1 ТБ? Ну на выходных запущу.
Какое здесь решение? Даже говорить об этом не хочется :)
Вне закона
И на последок крайний случай, который, что удивительно, можно часто встретить на этапах внедрения или в небольших компаниях. Суть его проста - у всех в системе выданы полные права. Все, кто там работает могут делать все что угодно. Из этого вытекают и предыдущие проблемы с внешними отчетами и обработка, а также другие проблемы с изменением данных. Тут уже не только изменение ключевых справочников, но и произвольное изменение учетной политики, изменение данных прошлых периодов и прочее "веселье". В любой момент времени может случиться все что угодно!
Решается это построением продуманных прав доступа всем пользователям системы. Добавить тут нечего.
Вы в безопасности
Конечно, часть информации выше имеет шуточный характер. Но в шутке есть только доля шутки. Часть случаев, но в некотором измененном виде, встречал на практике. Иногда хотелось смеяться, иногда плакать.
Поделитесь своими историями и забавными случаями в работе. Поделитесь щепоткой трэша и угара!
Другие ссылки
- В целях цензуры и здравого смысла другие ссылки не стал добавлять, но Вы можете оставить их в комментариях.
Авторские разработки
Транслятор запросов 1С в SQL - инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.
Просмотр и анализ структуры базы данных (отчет на СКД) - отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.
Просмотр и анализ журнала регистрации (отчет на СКД) - отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации.
История работы пользователей (отчет на СКД) - отчет для просмотра истории работы пользователей (СКД, просмотр для любого пользователя).
Экспорт журнала регистрации. Набор инструментов (приложения + исходный код) - набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux. Готовые приложения и исходный код.
Путеводитель по истории релизов - отчет по истории выпуска релизов продуктов фирмы "1С" и анализа информации по обновлениям.
-
Помощник работы с идентификаторами объектов - инструмент для расширенного анализа идентификаторов объектов.
Анализ производительности APDEX (бесплатный) - отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.
Обозреватель криптографии - отчет для просмотра доступных провайдеров и сертификатов криптографии на сервере и клиенте.
Пакетная выгрузка / загрузка внешних отчетов и обработок - пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.
Мастер полнотекстового поиска - набор инструментов для работы с полнотекстовым индексом платформы 1С. Стандартные и расширенные возможности.
Командный интерпретатор для 1С - инструмент для выполнения команд CMD / PowerShell из 1С
Часто натыкаюсь на внезапную "смерть" 1С (без сохранения данных). Но как то выкладывать данные фичи было совестно, а в форум пихать бесполезно, все таки ценность такие знания несут, возможно кто то и обойдет "грабли"! Сейчас собственно наткнулся на одну из фич и вспомнил что есть лайф.
Итак: Коллекция методов для вызова смерти 1СP.S. Методы буду вспоминать(или натыкаться) и выкладывать. Пишите на какие "грабли" вы наткнулись
Способы могут и не работать на Ваших машинах (то есть у Вас все будет работать нормально), но осведамлен, значит вооружен ;)
Способы для платформы 1С:Предприятие 8.1
Способ 1:
1. Установите Касперского (у меня 2009 думаю остальные еще круче "замочат" 1С) и оставьте все настройки по умолчанию. (касперский будет проверять все новые файлы).
2. Откройте конфигурацию и попытайтесь открыть Синтакс-помоцник. Вуаля. У меня вылетает окно с замечательными надписями "Закрыть или Перезагрузить". Хрен редьки не слаще.
P.S. Происходит вот что во время открытия синтакс-помощника создается временный файл, касперский его начинает проверять, но не успевает закончить как 1С уже ругается на ошибку разделенного доступа и вылетает самым гадким образом.
Способ 2: (от 29.09.2009)
Опять убил восьмерку, не в первый раз, но забыл уже о таком способе убийства.
1. Откройте Конфигуратор и Предприятие
2. Измените что нибудь в конфигурации и попытайтесь сохранить.
3. Если выпадет окно с кнопкой "Обновить динамически" то не спешите на нее нажимать. Перейдите в предприятие и закройте его и сразу же жмите кнопку "Обновить динамически". Вуаля мозг 1С взорвался. Хорошо еще что 1С умеет восстанавливаться после подобных ошибок при реструктуризации
Способы для платформы 1С:Предприятие 7.7
Откройте каталог базы там есть папка SYSLOG
правой кнопкой по ней.. поставь галку только для чтения.
И попробуйте зайти в конфигурацию (если не знаешь. то весело придется)Механизм РИБ — механизм распределенных информационных баз - это когда у вас есть главная база и подчиненная(ые). Главная база может быть только одна, подчиненных может быть много. Каждая подчиненная база может иметь свои подчиненные базы, для которых она будет главной.
Вот посмотрим на картинку из первой ссылки по запросу в Яндексе:
РИБ используется для обмена данными. Причем не только теми данными, с которыми работает пользователь, но и данными изменения конфигурации. То есть РИБ позволяет передавать изменения конфигурации. Но изменить конфигурацию можно только в главной базе!
Визуализируем:
У нас большая компания и много филиалов. Есть доработанная УНФ, которую мы гордо называем УБФ(Управление Большой Фирмой). Но мы решили, что хватит терпеть то, что все филиалы имеют доступ к документам всех филиалов и каждому филиалу решили сделать отдельную базу, которую синхронизировать с нашей основной базой для передачи данных. Что ж, можно. Сделали.
И внезапно мы решили изменить картинку, которая появляется при входе в базу, захотели поместить туда логотип нашей фирмы, а почему бы и нет?
Как запилить картинку во все базы всех филиалов? Ну при текущем варианте, что у всех филиалов отдельная база, только руками. Руками специалистов, которые умеют заходить в конфигуратор и знают что нужно там нажать.
А вот если бы мы сделали подчиненные базы для филиалов, то есть использовали РИБ, то и данными бы обменивались, как при обычной синхронизации, и картинка бы сама добавилась во все "базы-дочки". Однако, в конфигуратор зайти бы все-таки пришлось, но только чтобы нажать кнопочку "Обновить конфигурацию базы данных", вот картинка:
Как создать подчиненную базу, на пальцах:
я буду использовать Управление торговлей, редакция 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
В итоге у меня получится:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F"C:\Users\79119\Desktop\РИБ" /N"" /P"" /ResetMasterNode
Эта статья является продолжением цикла статей «Первые шаги в 1С». В ней рассмотрены типовые приемы восстановления базы 1С на платформе «1С:Предприятие 8» после сбоев. Предполагается, что база работает в файловом режиме работы. Восстановление базы в клиент-серверном режиме работы не рассматривается, т.к. данный вопрос явно выходит за рамки “первых” шагов начинающего специалиста.
Материал статьи детально раскроет ответы на следующие вопросы:
- Что нужно делать до начала всех работ по восстановлению? (копию, Карл!)
- Какие тонкости есть при использовании утилиты проверки?
- Какие средства для восстановления есть в конфигураторе?
- Когда и зачем нужно делать выгрузку/загрузку в формат *.dt?
- Если все вышеописанное не помогло, что можно еще попробовать?
Применимость
Статья написана для платформы «1С:Предприятие» версии 8.3.4.496, но не переживайте, если вы работаете с более старшей версией! Весь материал является абсолютно актуальным.
Как в 1С восстановить поврежденную базу «1С:Предприятие 8»
Порой для новичка данная задача кажется просто нереальной. Хотя, на самом деле, есть ряд нехитрых штатных средств тестирования баз 1С и приемов исправления возникающих ошибок.
Появление различного рода систематических сбоев (ошибок, неверно отображаемых данных, аварийное закрытие программы) можно считать повреждением базы.
Причины возникновения критических ошибок бывают разнообразными. Чаще всего проблемы возникают из-за сбоев электропитания.
С уверенностью можно сказать, что при клиент-серверном режиме работы база более устойчива к возникновению ошибок.
В рамках наших статей, мы будем рассматривать файловый режим работы базы. И первое, о чем нужно предупредить клиента – наличие источника бесперебойного питания на компьютере, где установлена информационная база, очень желательно.
Итак, главное не пугаться и перед попыткой восстановления базы сделать ее копию.
Например, можно сначала скопировать всю папку, в которой размещена база, а затем в этой папке оставить только файл 1Cv8.1CD (файл базы) и папку 1Cv8Log (журнал регистрации событий).
На самом деле, в большинстве случаев базы подлежат восстановлению. Некоторые 1С-ники это поняли и с радостью перехватывают таких клиентов. Самому делать в большинстве случаев ничего особенного не надо, клиент испуган, а работа тестовых программ занимает не малое время.
Перейдем к практике. Сначала выясните у клиента, как давно и при каких обстоятельствах стали возникать сбои. Узнайте, как пользователи осуществляют обновление конфигурации и как по времени связаны эти два события. Уточните объем базы.
Даже если в данном конкретном случае выясненные обстоятельства решающим образом на Ваши последующие действия не повлияют, Вы сможете собрать некоторую статистику, которая может пригодиться в будущем.
Обязательно узнайте, обновлялась ли платформа, и под каким релизом платформы база работала до этого.
Первым делом удалите все файлы и папки, которые в заданной директории окружают файл базы (1Cv8.1CD). Да, это некие служебные файлы, обеспечивающие полноценную работу, но точно отмечено, что иногда в работе этих файлов возникает некоторое рассогласование.
Ничего страшного не случится, потому что при очередном запуске базы все необходимые файлы будут созданы заново. С запуском мы пока повременим.
Теперь используем самое эффективное, но еще далеко не последнее, средство. В директории C:\Program Files\1cv82 (для платформы 8.3 – 1cv8)\(далее номер релиза платформы)\bin запустите утилиту chdbfl.exe.
Внимание! В каждом релизе платформы есть своя утилита chdbfl.exe. Целесообразно использовать утилиту из того релиза платформы, с которым использовалась данная база. В большинстве случаев – это последний установленный релиз платформы.
Здесь стоит сказать об одной особенности, если момент повреждения базы примерно совпадает с моментом обновления платформы, то утилита chdbfl.exe предыдущей платформы зачастую дает лучшие результаты в поиске и исправлении ошибок.
Однако рекомендуем идти сверху вниз (от старших релизов к младшим). В конечном итоге, первоначальная копия у Вас есть, и Вы всегда можете сделать еще одну копию и повторить весь цикл.
Однако если ошибки исправлены не все, но при этом отмечается уменьшение количества ошибок, то имеет смысл запустить утилиту еще раз.
Далее, даже если Вам удастся добиться нулевого количества ошибок, имеет смысл воспользоваться средствами тестирования и исправления в конфигураторе.
Сами параметры тестирования и исправления, если Вы абсолютно четко не понимаете, что именно делаете, лучше не трогать.
Улучшение результатов тестирования при повторном использовании данного средства не отмечено.
Следует еще сказать о средстве проверки конфигурации. По опыту, ошибки, отмечаемые данным средством, не отличаются особой критичностью. Скорее они просто замедляют работу самой базы. Что, по сути, для баз размером свыше 4 Гб пользователем может расцениваться тоже как повреждение базы.
4 Гб – это максимально допустимый размер не самой базы, а таблицы в базе. Но какой-нибудь регистр может быть значительно больше остальных и занимать большую часть размера базы.
В данной форме также без абсолютно четкого понимания никаких настроек менять не стоит.
Следует сказать еще об одном не совсем очевидном методе. Дело в том, что при выгрузке базы в файл с расширением dt существует крайне низкая вероятность, что загрузить его обратно не удастся.
Однако при загрузке происходит некая реструктуризация памяти, что в отдельных случаях позволяет восстановить работу базы путем последовательной выгрузки и загрузки.
Если после всех проведенных мероприятий и испытаний Вы обнаружили, что Ваша база остается поврежденной, то целесообразно использовать и это средство.
Выгрузка производится в конфигураторе через меню Администрирование, пункт Выгрузить информационную базу.
Появится диалоговое окно, в котором нужно будет указать направление выгрузки. Название создаваемого файла можно использовать по умолчанию – 1Cv8.dt.
Следует отметить, что выгрузка также является одним из возможных методов копирования.
Загрузку лучше всего производить в новую базу без конфигурации. Для создания такой базы в окне информационных баз нажмите на кнопку Добавить. На очередном шаге сохраните настройку Создание новой информационной базы и нажмите на кнопку Далее.
В появившейся форме поменяйте настройку на Создание информационной базы без конфигурации и также нажмите на кнопку Далее. На последующих двух шагах определите имя базы и директорию (пустую), в которой она будет находится.
Дополнительные параметры можно не заполнять и нажать на кнопку Готово. Будет создана информационная база без конфигурации.
Загрузка производится через меню Администрирование, пункт Загрузить информационную базу.
Далее появится диалоговое окно, в котором необходимо указать ранее выгруженный файл для загрузки.
Еще пару моментов. Если неисправности в работе базы отмечаются только на одном компьютере, следует попробовать поменять компьютер. Если неисправности проявляются только у одного пользователя, то следует попытаться пересоздать пользователя.
Иногда помогает удаление базы из списка в окне информационных баз с последующим добавлением в список той же существующей информационной базы (восстановление пути к ней).
В заключение хочется сказать, что, конечно, не все базы подлежат восстановлению, часть из них восстанавливается более сложными способами. Но не огорчайтесь, такие случаи бывают достаточно редко.
В качестве профилактики можно посоветовать производить обновление баз через конфигуратор и использовать штатные средства тестирования и исправления ошибок перед каждым обновлением. Пользователи, которые являются обладателями базовых версий и имеют право на бесплатное обновление, также могут предварительно скачивать файлы обновления с сайта.
В следующей статье рассмотрим возможности по настройке списка информационных баз.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Статья в PDF-формате
Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.
Комментарии / обсуждение (6):
Статья полезная, но есть 2 небольших замечания:
1.шаг №0 – делаем копию каталог базы!
2.размер 4Г – это максимально допустимый размер не самой базы а таблицы в базе. Как правило какой-нибудь регистр растёт значительно быстрее остальных. Для контроля размера таблиц можно использовать утилиту Tool_1CD. Ну хотя-бы изредка. При опасном приближении к предельному размеру нужно или выполнять свёртку базы или перевод на платформу клиент-сервер (сервера есть бесплатные(postgre, sql-expres) но серверный ключ приобрести нужно).Читайте также: