1с запрет выгрузки базы
Во многих базах 1С работают обмены данными и загрузки из различных источников в Базу-приемник. И было бы неплохо в такой ситуации дать возможность пользователю защитить объект (документ, справочник) в Базе-приемнике от повторного затирания следующими итерациями обменов. Это необходимо, например, когда объекты в Базу-приемник приходят частично или не совсем корректно заполненными и ответственные пользователи вручную проверяют пришедший объект и дозаполняют его до нужного состояния. Но не могут зафиксировать свою работу предотвратив случайное затирание при следующей загрузке.
Примечание: Стандартная дата запрета не защищает объекты 1С от изменения загрузками данных, т.к. не контролирует внесение изменений объекта в режиме ЭтотОбъект.ОбменДанными.Загрузка = Истина, в котором работают загрузки и обмены, поэтому требуется доработка контроля. Я, например, использовал это расширение при загрузках универсальным обменом данными из УПП в ЕРП в период перехода с одной базы на другую, вообще можно использовать при любых обменах между базами (см. ниже блок Проверка работоспособности в конфигурациях).
Немного о расширении:
Ниже пара простых примеров установки блокировки:
Блокируем документ прием на работу от изменения обменом, нажав кнопку защиты (на картинке - обмен открыт, - обмен закрыт)
Картинка изменяется, что значит что объект защищает от затирания повторными загрузками.
Также, например, можем за блокировать и сотрудника (напомню, что сотрудник и физическое лицо есть разные справочники, поэтому при необходимости физическое лицо блокируйте отдельно)
Также, например, можем за блокировать и контрагента (напомню, что контрагент и партнер есть разные справочники, поэтому при необходимости блокируйте их отдельно)
Работа расширения успешно проверено на платформе 1С:Предприятие 8.3 (8.3.18.1520) в конфигурациях:
- 1С:ERP Управление предприятием 2 (2.4.11.91, 2.5.7.201)
- 1С:Комплексная автоматизация 2 (2.4.9.98)
- 1С:Управление торговлей, редакция 11 (11.4.8.84)
- 1С:Зарплата и управление персоналом, редакция 3.1 (3.1.18.337, 3.1.20.97)
- 1С:Бухгалтерия предприятия, редакция 3.0 (3.0.106.60)
Т.к. в расширении подписки на события используются, то Режим совместимости конфигурации нужен от Версия 8.3.16 (либо удаляйте подписки из расширения и делайте перехват процедур от подписок перед записью из конфигурации)
Расширение использует универсальные механизмы, общие для многих продуктов 1С, поэтому может быть подключено к разным продуктам 1С либо доработано с минимальными затратами. Конфигурация продукта 1С должна быть построена на базе БСП (Библиотеки стандартных подсистем, входит в типовые конфигурации 8.3)
ВЕРСИИ ДЛЯ СКАЧИВАНИЯ:
-
Расширение: Защита объектов от изменения обменом (версия 04.01.2022 с отказом) - При загрузка выполняется отказ от записи защищенного объекта, нужно сочетать с признаком продолжения загрузки при возникновении ошибки, либо анализировать и убирать из регистрации в источнике запрещенный объект. Обратите внимание, что
ЭтотОбъект.ОбменДанными.Загрузка=Истина может вызываться, например, в обработке редакторе объекта
и других местах, поэтому можно в код добавить проверку пользователя или специальной роли. Так на автообмены для фонового обычно выделяют определенного пользователя и можно добавить проверку на его имя. Вообщем, код открыт, используйте расширение как шаблон, дополняя по своей специфике. Вместо подписок на событие в Правилах обмена можно обращаться к регистру, хранящему защищенные объекты и выполнять отказ от записи объекта (зависит от контекста задачи).
Подключить расширение может в режиме конфигуратора Администратор1С (описание он сам знает) либо Пользователь1С, открыв 1С:Предприятие, и далее в главном окне:
1) Переходим в Главное меню - Настройки - Параметры - Режим технического специалиста;
2) Переходим в Главное меню - Функции для технического специалиста - Стандартные - Управление расширениями конфигурации - Добавляем расширение;
3) Перезапускаем сеанс 1С:Предприятие;
Рис. Форма подключения расширения
Обработка выгрузки и загрузки данных через XML между идентичными конфигурациями с возможностью установки произвольных отборов на выгружаемые объекты.
Подключаемый отчет на системе компоновки данных по типам объектов 1С показывает: 1) Совокупности таблиц SQL для хранения объекта 1С и их предназначение; 2) Число объектов данного типа; 3) Размеры хранения данных и индексов в MB (мегабайтах); 4) Сравнение данных двух баз
Предназначается для запуска сеанса другого пользователя из своего сеанса 1С (если пароль вам неизвестен).
Если пользователю не хватает прав на объект, то на практике в 90 % случаев, недостающую роль можно найти через типовой регистр сведений Права ролей. Также с помощью дополнительного отчета или небольшого расширения можно ускорить описанный процесс.
Онлайн диаграмма доступных лицензий 1С и показателей ресурсов сервера 1С в различных измерениях и отборах.
Обработка ищет все объекты базы, в которых одновременно присутствуют перечисленные элементы. Построена на базе типовой обработки Все функции - Стандартные - Поиск ссылок на объект, но позволяет накладывать отбор не по одному объекту, а по нескольким, что позволяет настраивать поиск по комбинациям условий
Часто не хватает визуализации хронологии документов в структуре подчиненности и кнопок проведения. Это расширение конфигурации, с функционалом структуры подчиненности документов, отображающее хронологическую последовательность документов во времени и дающее доступ к проведению, отмене проведения, пометке на удаление документов непосредственно в форме подчиненности.
Обработка для массовой проверки доработок конфигурации: Открытие форм, Печать, Формирование отчетов, Проведение документов, Запись справочников, ПВХ, ПВР. Выдает список обнаруженных ошибок. Рекомендуется применять для тестирования обновленной конфигурации, перед установкой пользователям. В коде используются универсальные методы поэтому подходит для большинства конфигураций, построенных на базе библиотеки стандартных подсистем.
Групповая обработка ссылок вида Объект не найден (502:37855254002e11eb11e73b8f36150d9e) заполняется максимально просто копированием и вставкой из буфера: 1) Выделяет уникальные идентификаторы (далее УИ); 2) Ищет ссылки на объекты базы по УИ; 3) Создаёт пустые объекты с указанным УИ; 4) Регистрирует найденные ссылки для обмена данными. Работает на любых продуктах 8.3
Обработка на управляемых формах для работы с календарями google, событиями календарей и контактами.
Обработка проверяет наличие и решает проблему с ошибкой развернутого сальдо в Оборотно-сальдовой ведомости (регистр бухгалтерии Хозрасчетный) из-за ошибки Универсального редактора реквизитов или кода программиста, устанавливающего пустые ссылки в значениях Валюты, Подразделения, Направления деятельности не равными NULL. И пересчёт итогов тут точно не поможет.
Выполнил 3 разных теста для проверки серверного оборудования (тест 1С, тесты gilev) на возможное число 1С онлайн-пользователей одновременно работающих на нем и интерпретировал результаты тестов через легких, средних и тяжелых пользователей с помощью таблицы с профилями реальных пользователей.
Перед началом проекта требуется определить параметры серверного и клиентского оборудования, необходимые для работы внедряемой программы 1С:Предприятие, и учесть будущую нагрузку, которая ляжет на систему в реальной рабочей обстановке. Мощность оборудования должна быть достаточной для нормальной работы пользователей. Но как подобрать сервер простым способом?
На время сеанса отключаем контроль остатков и проверку документов в ERP, КА, УТ типовыми средствами и простым расширением.
Часто при моделировании примеров бизнес-процессов, на запуске в эксплуатацию или закрытии требуется несколько раз прогнать ситуацию с разными настройками, а для этого изменить, удалить ранее введенную цепочку документов. Дается все это с трудом. Ты уверен, что не навредишь своими действиями системе, но документы цепляют друг друга и ругаются контролями остатков, не разрешая тебе менять их в произвольном порядке.
Есть несколько удобных опций для облегчения внесения изменений.
Для уведомления пользователей программных продуктов 1С о разных событиях, в них включена подсистема «Новостной центр». Это довольно удобная штука, т.к. новостные ленты сообщают о выходе обновлений, о новостях и событиях в сфере учёта. Но можно увеличить пользу от новостной подсистемы используя её локально в рамках 1С базы. Например, внутренняя служба техподдержки или внедряющая компания может через новостную ленту оповещать пользователей информационной базы об изменениях в программе, совещаниях, проведении тестирований, заполнения нужных документов или сдача отчетов к определенной дате и т.п.
Пример технического задания для практического понимания основных разделов.
Кратко описаны основополагающие моменты при старте групповой разработки конфигурации несколькими программистами. Полезно для проектной документации как требование к разработчикам или сопровождающей компании
Сразу скажу что я не 1С-к я системный администратор. 1С-ники на аутсорте говорят что просто много
данных. База ведется с 2015 г., но внятно объяснить почему такая разница между SQL и dt-шкой они не могут
Понять почему база стала такой большой.
База весит 164 Гб. При выгрузке в dt файл 5 Гб
Что было проверено:
1. Выгрузка в dt-шку и загрузка в чистую SQL базу результатов не дала, размер базы остался таким же.
2. В SQL-ке к этой базе ежедневно применяются:
a. Перестроение индекса
Серверная версия SQL 1С:Предприятие 8.3 (8.3.16.1814) Управление торговлей, редакция 11 (11.4.13.103)
(0) Нормальное сжатие SQL базы, если там нет картинок 1 к 10. То есть 164 Гб база, должна весить примерно 15-17Гб.
Скорее всего не настроено shrink в SQL, данные мусорные копятся.
(0) А что мешает посмотреть размер таблиц в SQL.
С учетом "выгрузка в dt-шку и загрузка в чистую SQL базу результатов не дала" главный подозреваемый - итоги регистров. Но 170ГБ это очень много
В MSQL SMS не дает сжать базу через интерфейс:
Модель восстановления - простая
Да нифига не надо сжимать, если кушать не просит. А без предварительного анализа на потенциал "сжатия" - и подавно.
(0) А в чем проблема с размером? База плохо работает или что?
А разница между SQL и dt объясняется тем, что dt сжатый.
Размер данных 10 429 512
Размер индекса 8 376 680
Общий размер 18 806 512
Количество строк данных 49 540 167
(18) Хм. Странно.
Да, много занимают итоги регистров. И из них много занимают их индексы (возможно есть "лишние").
Причем мне недавно убедительно доказывали, что выгрузка в dt происходит вместе с итогами. Что косвенно подтверждает тот факт, что загрузка dt в пустую базу результатов не дала.
Получается, что просто хорошо жмется все это дело при выгрузке в dt. Можно попробовать полный пересчет итогов, но неизвестно сколько он займет и вряд ли будет такой уж большой эффект от удаления лишних записей таблиц итогов. Короче от тебя как от админа тут мало что зависит. Нужно анализировать ситуацию из прикладной части.
(0) Покажи свойства FILES системной базы model
(25)Посмотри регистр вручную, с сортировкой по самой ранней даты - может там типа дата 1800 .
ТОже не понимаю истерии с dt. С 2006 году бекапы через dt делаю. Постоянно приходиться восстанавливать по разным причинам. Проблем нет.
Размер dt 3 Гига
(0) потому-что сама 1С писала письмо, что dt нужно делать для переноса баз, а более правильно средствами БД или папку целиком (если файловая). Так больше вероятности, что бэкап не превратится в тыкву
(14) "механизм предназначен, прежде всего, для получения образа информационной базы независимо от способа хранения данных." Точка.э
(17) запятая, э. читай внимательно. что dt нифига не гарантирует, а только является средством конвертации из файловой в серверную и наоборот
(17) Там дальше продолжение: "Использование этих способов [отличных от dt] дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных."
"Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных."
Они уже официально оговорили, что все на страх и риск пользователя :)
Я делал раньше бекапы файловой в dt. А потом они у меня совсем не захотели загружатся в тяжкий для меня момент. Больше я в dt не бэкаплю. Такая грустная история((
(19) С другой стороны, бывают ситуации, что эти нарушения можно лечатся только выгрузкой/загрузкой *.dt. Так что, тут бабушка надвое сказала.
(22) Есть такое. Но бэкап средствами СУБД (или копирование папки файловой базы) сохраняет исходное состояние базы, а загрузка/выгрузка это состояние меняет (как минимум, не сохраняются данные индексов). В случае сбоя всегда лучше изменять данные по минимуму -- так больше шансов что-то вытащить
Если в СУБД косяк с итогами, то выгрузка/загрузка изменит картину: восстановленная база из dt не будет точной копией, а иногда это необходимо (например, баланс уже сдан с "кривыми" итогами и надо сделать копию в том же виде для разборов)
(0) dt использую для загрузки в тестовую базу для разработки/доработки и пр.
Ну и для бэкапа, каждый день.
Но главный бэкап это конечно же средствами скуля.
(34) Франч? На повременке? У меня база 120 гигов. Выгрузить в дт/загрузить из дт сколько времени будет занимать?
(36) нет, я фикси в молодой строительной фирме. Мне пока можно делать dt :) Размер его пока что ~ 800 метров
(35) Да не завожусь я :)
Например (32). Смысл архивной копии: В случае сбоя поднять базу в том же состоянии, в каком она была на момент бекапа. Так же важно время, за которое можно отресториться в случае сбоя.
(38) Ну, у меня не все базы такого большого размера. :)
(39) А из dt - не поднять?
Я понимаю, что выгрузка изменяет (те же индексы). Но в случае сбоя - так ли уж важны индексы?
На стройках кирпичи не каждый день на головы падают, и даже не каждый год. Но это не отменяет каски. Так и с dt - у кого-то может с 2000-го года всё быть в порядке, а у кого-то и через полгода может случиться косяк в базе, который не даст восстановить бэкап из dt. А вот обычный архив папки с базой (в файловом варианте) будет проще восстановить.
(46) При загрузке из дт, как минимум, пересчитываются итоги. Дальше, думаю можно не продолжать.
Пруфа нет.
(47) (48) ааа, извиняюсь! не так понял.
Я прочитал как "обрАботка может поплыть" )))
Думаю, нихренасе, внешние обработки может исказить)
(49) Выше писала: у был один раз форс-мажор - не загрузился dt. Но там и база была подыхающая. Один раз это какой процент?
(52) "Основным недостатком такого способа создания резервной копии является необходимость использования однопользовательского режима для осуществления этой операции. При большом объеме информационной базы перерыв в работе пользователей может быть достаточно велик, что не всегда приемлемо." - для меня в этом проблемы нет.
(53) Что ж вы все дальше не читаете-то? Я еще раз могу повторить: "Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы". Еще проще -- если восстановиться из бэкапа скуля, его еще можно испортить загрузкой/выгрузкой. А вот обратное уже не работает.
А я считаю так: кто хочет делать бэкапы в dt, пусть делает. Ну если не учит чужой опыт людей и рекомендации производителя ПО им тоже ни о чём, то что тут поделаешь.
Да не загружается dt вот и всё! (в случае битых баз), а чтоб не битые были надо ТиИ а перед этим бекап. У меня один раз не развернулся. Опыту.
Для тех кто в танке (ну то есть на документацию) на Большой Партнёрке Нуралиев сказал (вольно к тексту): dt - для переноса из файлового в серверный и наоборот, бекап в файле (тока файл 1CD, в монопольном доступе) в сервере средствами СУБД. Всё!
(5) Не знаю что там с вашими обезьянками, а я лично сталкивался со случаями отказа восстановления БД из dt по меньшей мере дважды.
А дальше можете хоть обделаться, рассказывая как 100500 миллионов раз вы выгружали и успешно восстанавливали базы через dt-шник.
Никакие самые авторитетные мнения не смогут заменить личного печального опыта в таком вопросе.
PS. Лезьте за своим бананом. Я вам мешать не стану.
(58) Аналогично. Работало, работало. А потом бац и перестало загружаться. Хорошо резервирование настроено другими средствами. Надо было рядом копию базы сделать, но не удалось. Всему виной было превышение размера внутреннего файла.
(0) Даже не принимая во внимание страшилки про незагружаемые dt, SQL быстрее же и выгонять никого не надо, не?
А вот интересно, для тех у кого файловая, архивный копии тоже через DT выкручивают или все-таки архиватором непосредственно каталог базы или файл базы архивируют?
Я лично делаю так, как доступно. Если прав админа на сервер у меня нет, а бакап нужно делать, то выгружаю в DT, чтоб можно было без сервера на локальной машине поднять. Но для очень больших баз или для тормозного сервера таким методом не получится. Не говоря уже о том, что "битые" данные DT не лечит, а окончательно убивает.
(0) Сможет так случиться, что в файловой верии размер одной таблицы базы превысит 4 Гб. Соответственно, в этом случае, выгрузка пойдет болтом.
Про скульные бекапы, гут да. Но нужно один раз поморочиться, если бекапы нужны ежечасные, покурить все эти транзакшн-логи и т.д.
Насколько я понимаю, что видел у продвинутых людей, разностные бекапы делаются не только на уровне SQL, но и самим акронисом всего сервера СУБД. На тот случай, если совсем все плохо станет ;)
(0) 1.Если база файловая - быстрее скопировать, если серверная - быстрее сделаит бэкап средствами базовода.
2.с вероятностью до 1% база из DT не будет восстановлена.
(5) В отчете SQL размер временных таблиц превышает 4 Гига? У нас превышает и не грузится. Таблица регистра версионирования.
Единственный плюс копирования всей файловой базы это журнал регистрации
А дт это по сути сначала чекдбф а потом зип
Ничего нежелательного нет.
Можно спокойно выгружать базу в dt.
Главное архивы с помощью такой выгрузки не делайте.
(64)Архивные копии всегда делают средствами СУБД.
Если sql - значит средствами скуля.
Если файловая - значит средствами файловой системы.
1)делается теневая копия диска содержащего файл 1с.
2)монтируется теневая копия и файл упаковывается архиватором.
3)файл отсылается в место хранения, и формируется отчет.
(51) Вы матстатистику и теорвер будете финику, гендиру и главбуху объяснять, когда бэкап базы не взлетит за день до сдачи отчетности и компания влетит на штраф в десяток-другой лямов :)
В вопросах бэкапов вопрос не в том, что МОЖЕТ НЕ произойти, а вот, что МОЖЕТ произойти. Если вы не понимаете эту азбучную истину, то рано или поздно поймете на своем опыте.
Если из dt база не восстанавливается, то её уже нет. Возможно, давно. Поэтому и нужно выгружать в dt, чтобы база жила. Желательно её потом восстанавливать в файловую. Если очень большая, не получится.
(0) Потому что зачем делать лишние преобразования данных, причем теоретически могут быть проблемы при восстановлении из dt. Упакуй *.cd в zip и получишь примерно то же.
(0) По сравнению с backup MS SQL во-первых дольше как ВЫгружать, так и ЗАгружать, во-вторых появляется необходимость выгонять пользователей, в-третьих нет преимущества в объеме хранимых данных (сжатый backup, насколько мне известно, весит примерно столько же сколько dt).
(80) SQL - это не стандартно. Это не 1с. А dt - стандартно.И 1с гарантирует, что это всегда будет работать.
(79) и получишь нерабочую базу, так как выгрузка в dt гарантирует что в этот момент в базе никто не работает и не проводит документы или не сохраняет конфигурацию
нет, просто с 2006 выгружаю в dt и проблем не наблюдаю, в отличие от копирования cd файла, когда в этот момент юзверь проводит документ, или от копирования bak файла скуля, когда в нужный момент оказывается не та версия скуля, а какая там была никто не помнит
(90)Ну у каждого свой негативный опыт. Хорошо когда есть альтернатива.Поэтому не вижу причины, с упорством фанатика, заставлять всех переходить в свой лагерь и всех противников объявлять еретиками и призывать придать их анафеме
(91) Да, собственно, конечно есть.
Но в данном случае:
1. Делать копии файла 1CD рекомендует сама 1С.
2. Делать бекапы средствами скуля, а не выгрузкой в DT опять же рекомендует сама 1С. И более того, скулем можно делать выгрузку без выгона пользователей и автоматически. А вот в DT с выгоном и по праздникам.
(91) +1. Всё правильно сказал.
Я, например, не пытаюсь никого убедить в том, что архив в *.dt лучше/хуже других методов. Я просто говорю, что проблем с *.dt я ни разу не встречал.
Вообще, я считаю, что все эти проблемы с *.dt были на заре 1Cv8, но сейчас уже весь код платформы отлажен в этом сегменте и всё стабильно хорошо.
А переубеждать кого-то я не собираюсь - не вижу смысла. Каждый сам выбирает себе путь. Я себе уже выбрал.
Аналогично. Регулярно делаю дэтэшники, но естественно sql-сервер регулярно своими средствами бэкапит по плану.
(92) у скулевских бэкапов есть проблемка. не развернуть в файловом варианте на локальной машине для ковыряния :)
У кого-нибудь есть инструкция для чайника резервного архивирования средствами SQL во внешний файл, чтобы можно было спокойно брать вчерашний день и загружать в другой SQL в другом месте?
(96) примерно так, справедливо для MS SL2008 Express (не претендую на истину в последней инстанции):
1. делаем файлик, например BackSQL.sql со следующим содержимым:
BACKUP DATABASE [имя БД] TO DISK = N'E:\BackUpSQL\имя Файла архива.bk' WITH NOFORMAT, NOINIT, NAME = N'Понятное название латиницей', SKIP, NOREWIND, NOUNLOAD
GO
это же можно получить из SQL Server Management Studio, делай как больше нравится.
пишем bat файл:
start /wait osql -U -P -i BackSQL.sql
можешь добавить сжатие полученной копии в rar или zip.
Ставим его в виндовый шедулер с запуском, например, через каждый час. Получаем ежечасную, автоматическую копию базы данных, но тут есть одна особенность: файл резервной копии дополняется(. ) каждый раз, так что придётся выстроить механизм его перемещения вечером или сразу после создания, что-бы не вырос до безобразия.
Для полной версии можешь задействовать план обслуживания. будет несколько проще.
Для получения полной резервной копии всей БД:
rem Разделение даты на составляющие исходя из формата 20.10.2006
for /F "TOKENS=1,2,3 DELIMS=." %%a in ('Date /T') do (set day=%%a)&&(set mon=%%b)&&(set year=%%c)
rem set year=%year:~0,4%
rem set day=%day:~3,2% если есть ПТ 20.10.2006
net stop MSSQLSERVER
net stop sqlbrowser
net stop sqlwriter
start /wait %hom%\rar a -y %hom%\1\Full\%dt%-SQL-Buh %path1С%\ - забираем БД и файлы журнала
rem стартуем сервисы
net start MSSQLSERVER
net start sqlbrowser
net start sqlwriter
Обрати внимание: копии создадутся на том же диске что и сама БД, поменяй пути и настрой копирование куда-нить кроме как локальная машина.
Для начала хватит, а дальше сам разберёшься.
ВАЖНО! Перед выполнением синхронизации данных между базами 1С: необходимо установить даты запрета загрузки.
В случае, если данные баз уже были синхронизированы за определенный месяц, информация была передана из базы-источника в базу-приемника, и необходимо исключить возможность обратного переноса информации из базы-приемника либо из базы-источника, необходимо установить Дату запрета загрузки.
Для этого в Администрировании - Синхронизации данных в поле Дата запрета загрузки должна быть установлена галка (см. рис. ниже). Далее переходим по ссылке Настроить.
Рисунок 1 - Синхронизация данных
В открывшейся форме по ссылке Настроить в поле Дата запрета необходимо указать дату конца месяца, в котором уже была проведена синхронизация:
Рисунок 2 - Даты запрета загрузки данных
ВАЖНО! Даты запрета загрузки необходимо устанавливать концом месяца после завершения синхронизации по текущему месяцу, как в базе-приемника, так и в базе-источника.
Установка даты запрета редактирования
Для установки даты запрета изменения данных в программе 1С необходимо перейти по навигации: Администрирование / Настройки пользователей и прав (скрин на примере базы 1С: ЗУП).
Рисунок 3 - Настройки пользователей и прав
В открывшемся окне перейти в раздел «Даты запрета изменения». Установленный одноименный флаг означает, что настройка запрета изменения данных прошлых периодов включена.
Рисунок 4 - Настройки пользователей и прав
Нажатием по гиперссылке «Настроить», пользователь открывает окно редактирования даты. Предварительно необходимо проанализировать, дата запрета устанавливается общей для всех пользователей или только для определенных сотрудников, и перейти на соответствующую вкладку.
На вкладке «Для всех пользователей» устанавливается общая дата запрета в поле «Дата запрета», раньше которой запрещено изменение данных. Ограничение применяется для всех пользователей системы, всех подсистем и объектов.
Рисунок 5 - Дата запрета изменение данных
На вкладке «По пользователям» существует возможность указать дату запрета для определенных пользователей или групп пользователей. Для группы «Для всех пользователей» можно аналогичным образом добавить общую дату запрета.
Рисунок 6 - Дата запрета изменение данных «Для всех пользователей»
Нажатием кнопки «Подобрать» на панели действий, пользователь может добавить пользователей или группы в табличную часть и указать для них отличные даты.
Продукты фирмы «1С» имеют два основных решения для хранения данных: файловая база данных и база данных, размещенная на SQL Server. В данной статье мы рассмотрим два варианта переноса баз данных 1С с сервера на сервер (с компьютера на сервер).
Если вам необходимо перенести базы 1С в облако, то мы можем сделать это бесплатно в рамках услуги аренда сервера 1С.
Вариант №1 – Перенос базы с помощью выгрузки .dt формата (применимо как к файловым базам, так и к серверным):
- Необходимо открыть базу, которую собираетесь переносить в режиме конфигуратора:
Скриншот 1. Окно со списком баз 1С
- В конфигураторе необходимо выбрать пункт меню «Администрирование» и «Выгрузить информационную базу»:
Скриншот 2. Режим конфигуратора
- В момент запуска процесса выгрузки конфигуратор предложит путь, куда нужно сохранить базу. Указываете путь и нажимаете сохранить.
Скриншот 3. Выбор директории для выгрузки
- Как только конфигуратор закончит выгрузку базы данных, он выдаст информационное окно, что выгрузка информационной базы завершена.
Скриншот 4. Информационное окно, что всё прошло успешно
- Готовая выгрузка для переноса на другой сервер.
Скриншот 5. Выгрузка в выбранной нами папке
- Переносим файл формата .dt с сервера на сервер любым удобным для нас способом (с помощью флэш-накопителя, через облако).
- После того как перенос базы выполнен нам необходимо создать пустую базу и загрузить в неё нашу выгрузку (в нашем примере мы примере мы создадим пустую файловую базу).
- Создание базы данных происходит следующим образом (согласно скриншотам).
Скриншот 6. Окно добавления информационной базы
Скриншот 7. Окно добавления информационной базы
Скриншот 8. Окно добавления информационной базы
Скриншот 9. Окно добавления информационной базы
Скриншот 10. Окно добавления информационной базы
- Далее заходим в нашу базу в режиме конфигуратора.
Скриншот 11. Окно со списком баз 1С
- Во вкладке администрирование выбираем пункт «Загрузить информационную базу», указываем путь и выбираем нашу выгрузку.
Скриншот 12. Режим конфигуратора
Скриншот 13. Директория где находится перенесенная нами выгрузка
- Конфигуратор выдаст нам следующее окно. Нажимаем «Да».
Скриншот 14. Диалоговое окно в режиме конфигуратора
- Наша выгрузка успешна загружена в нашу пустую базу. Перенос базы выполнен, о чем нам рапортует конфигуратор.
Скриншот 15. Диалоговое окно в режиме конфигуратора
Вариант №2. Перенос базы данных 1с SQL.
- Заходим в Microsoft SQL Server Management Studio (MSSMS), вводим уч.данные администратора баз данных.
- Далее кликаем правой кнопкой мыши по базе, которую нужно перенести и выбираем пункт «Создать резервную копию…».
Скриншот 16. Консоль администрирования MS SQL
- Во вкладке общее выбираем тип архивной копии «Полная» и назначение «Диск» и нажимаем кнопку «Добавить».
Скриншот 17. Окно «Резервное копирование базы данных»
- Выбираем путь, тип резервной копии «.bak» и назначаем имя нашему бэкапу.
Скриншот 18. Окно с выбором пути для бэкапа базы
- Во вкладке «Параметры носителя» в графе «Надежность» кликаем в чекбокс «Проверить резервную копию после завершения», для того чтобы быть уверенным в том, что резервная копия будет корректной.
Скриншот 19. Окно «Резервное копирование базы данных»
- Для того, чтобы уменьшить размер нашего бэкапа базы 1С во вкладке «Параметры резервного копирования» в графе «Сжатие» выбираем опцию «Сжимать резервные копии» и нажимаем «ОК». Далее пойдет процесс выполнения бэкапа.
Скриншот 20. Окно «Резервное копирование базы данных»
- Как только бэкап нашей базы будет создан появится информационное окно:
Скриншот 21. Информационное окно
- Далее переносим нашу базу на новый сервер любым удобным для нас способом.
ВАЖНО! В нашем примере мы не учитываем совместимость MS SQL серверов. Для того, чтобы бэкап базы данных успешно развернулся на новом сервере, версия MS SQL сервера должна быть либо такой же, либо выше (режим обратной совместимости), чем на старом сервере.
Читайте также: