Восстановление работоспособности SQL базы «1С предприятие 8» после падения во время обновления

Приветствую Вас, дорогие читатели.

Совсем недавно мне пришлось восстанавливать базу «1С предприятие 8» после падения, которое произошло во время обновления конфигурации. Причем это было дважды и методы примененные при восстановлении тоже были разными (скоро узнаете почему). В данной статье я хочу рассказать о тех способах, которыми я воспользовался.

Все способы рассматриваемые в статье относятся к серверному варианту работу «1С предприятие 8», используемое СУБД — MS SQL 2005.

Случай №1.

При обновлении конфигурации была выдана ошибка «Конфликт блокировок», конфигуратор был закрыт. При повторной попытке входа в конфигуратор появилась ошибка: Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»

Ошибка №1 после обновления

При положительном ответе выдавалось следующее сообщение «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»

Ошибка №2 после обновления

Поиски на просторах интернета выдали следующий способ. В таблице Config нашей базы данные необходимо удалить строки где поле FileName = commit или FileName = dbStruFinal или FileName=DynamicallyUpdated (для 8.3) или FileName=dynamicCommit (8.3), а также очистить таблицу ConfigSave. Поясню за что отвечают данные таблицы: Config — в данной таблице хранится конфигурация базы данных, ConfigSave — в данной таблице хранится рабочая конфигурация, т.е. до нажатия кнопки F7 в конфигураторе.

Открываем SQL Serger Managment Studio и открываем окно запросов по кнопке «New Query» открывает окно запросов.

Открыть окно запросов

В окне запросов пишем запросы и выполняем их:

  1. delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘commit’
  2. delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘dbStruFinal’
  3. delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘DynamicallyUpdated’ (для версии 8.3)
  4. delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘dynamicCommit’ (для версии 8.3)
  5. delete from [ИмяНашейБазы].[dbo].[ConfigSave] 

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

Случай №2

Причина ошибки входа в конфигуратор такая же как и в первом случае: конфликт блокировок при обновлении конфигурации.

Удаление строк в таблице Config и очистка таблицы ConfigSave помогло частично: конфигуратор открывался, но в предприятии не работали управляемые формы.

В данном случае приходило в голову 2 пути развития:

  1. Восстановление из архива. В данном варианте было одно большое  «НО»: так получилось что архив создался уже после обновления, т.е. архив был с ошибкой.
  2. Была идея использовать конфигурацию распределенной базы, которая не обновилась, потому что файл для обмена был с ошибкой.

Для решения проблемы был выбран 2-ой вариант. Далее пошагово расскажу что делал.

  1. Открываем SQL Serger Managment Studio и создаем произвольную базу, например Perenos. В этой базе создаем таблицу Config. Кто не знает sql для переноса данных из одной таблицы в другую, то у MS SQL есть замечательный сервис «SQL Server import and Export Wizard«. С помощью данного сервиса можно легко переносить данные из одной базу в другую. Чтобы запустить данный сервис необходимо нажать клавиши «ctrl+r» и в окне диалога написать команду «dtswizard«.
  2. Переносим с помощью сервиса dtswizard данные таблицы Config нашей базы в таблицу Config базы Perenos.
  3. Очищаем таблицу Config в нашей базе с помощью запроса delete from [ИмяНашейБазы].[dbo].[Config]
  4. На сервере, где находится распределенная база запускаем сервис dtswizard и переносим данные из таблицы Config в такую же таблицу только в нашей базе.

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

Популярность: 29%

Рубрика: Настройка и оптимизация | Метки: | 4 комментария

Правильные запросы в 1С

Здравствуйте, дорогие читатели!

Самым быстрым по производительности способом получения данных в системе «1С Предприятие 8» является работа с запросом. Поэтому чаще всего Вам придется пользоваться именно этой техникой.

Запрос представляет собой текст на специальном языке запросов. В этом тексте
описывается, что является источником информации для запроса, а также
указываются условия для построения запроса. Более приближенно к системе
«1С Предприятие» источник информации можно определить так: какие таблицы
информационной базы используются в качестве источников данных для запроса,
а также какие поля таблиц требуется обрабатывать в запросе. А вот какими подходами и методами при этом руководствоваться – в большинстве случаев это остается на усмотрение сервера «1С Предприятия» (который переводит наш запрос на языке 1С на язык запросов СУБД) и оптимизатора СУБД (который подбирает оптимальный сценарий получения данных).

Например: В своем запросе мы требуем отобрать из справочника «Номенклатура» все услуги, основным поставщиком которых является «Абдулов». При этом реквизит «Услуга» булевого типа, а реквизит «ОсновнойПоставщик» — тип справочник «Контрагенты». Оба реквизита индексированы.

Для оптимизатора СУБД есть несколько вариантов выполнения этого запроса:

  • Найти по индексу поля «Услуга» записи, удовлетворяющие первому условию и проверить среди них второе условие.
  • Прочитать все записи таблицы «Номенклатура» и отобрать по двум условиям нужные нам данные
  • Найти по индексу поля «Основной поставщик» записи, удовлетворяющие второму условию и проверить среди них первое условие.

Оптимизатор СУБД выбирает и анализирует лишь некоторое количество вариантов выполнения запроса и выбирает «лучший из них».  При этом возникает вероятность, что по-настоящему оптимальный вариант остался даже не рассмотренным. Поэтому чтобы помочь оптимизатору СУБД в выборе оптимального варианта выполнения нашего запроса рекомендуется придерживаться следующих правил:

  1. По возможности условие ИЛИ заменять  операцией ОБЪЕДИНИТЬ ВСЕ. Чтобы убедиться в том, что нужна замена, можно сделать так: выполнить запрос с условием на равенство по одиночному значению поля, а потом запрос с условием ИЛИ по этому полю на большой таблице. Если второй запрос выполняется намного дольше, чем первый, то данный запрос можно переписать.
  2. Условие «не равно» (<>) тоже может отключать использование индекса. Например если необходимо исключить большую часть таблицы, а поле отбора проиндексировано, – есть смысл переписать запрос на вариант ОБЪЕДИНИТЬ ВСЕ
  3. В условиях соединений, стараться обходиться без использования вложенных запросов и виртуальных таблиц, а так же лишних разыменований (выражений через несколько точек). Вложенные запросы и виртуальные таблицы рекомендую заменить на временные таблицы.
  4. Стараться избегать в условии «В ИЕРАРХИИ» содержания пустой ссылки. Возможно ситуация когда оптимизатор СУБД начнет проверять каждый элемент справочника на принадлежность корню (т.е. самому справочнику), теряя на этом время.
  5. Следует использовать ОБЪЕДИНИТЬ ВСЕ вместо ОБЪЕДИНИТЬ, если наличие одинаковых записей не критично. Оператор ОБЪЕДИНИТЬ использует дополнительные операции, которые могут занять много времени.
  6.  Условие «ПОДОБНО» подавляет использование индекса.
  7.  Если запрос содержит несколько условий, то они должны располагаться в порядке уменьшения эффекта от выбора. То есть первым надо делать то условие, которое максимально уменьшит результирующую таблицу.
  8. Максимально использовать индексы таблиц. Необходимо стараться чтобы для всех условий, использованных в запросе, имелись подходящие индексы. Подходящий индекс — это индекс, который содержит все поля перечисленные в условии, эти поля находятся в самом начале индекса и они расположены вместе, т.е между ними нет других полей.
  9. Не рекомендуется фильтровать виртуальные таблицы при помощи условий в секции ГДЕ и т.п. Надо использовать только параметры.
  10. Стараться для ссылочных полей, по которым будет вывод, получать представление  сразу в запросе, т.е. использовать конструкцию «ПРЕДСТАВЛЕНИЕ(НашаСсылка)«
  11. Если в запросе реализовано соединение двух и более таблиц, то эти таблицы должны стоять в запросе в порядке уменьшения количества записей в них, а в части условий (ГДЕ) первым должно стоять условие на первую таблицу.
  12. Если запрос содержит условие для проиндексированного (относится к некластерному индексу) поля маленькой таблицы, которая может быть считана за одно обращение к памяти, то лучше убрать индекс с этого поля в конфигурации.
  13.  Условия вхождения значений полей в результаты вложенных запросов лучше заменять на внутренние соединение по равенству этого поля для ситуаций, когда есть вероятность получения больших размеров таблиц результатов вложенных запросов. Т.е. конструкцию «Поле1 В (Выбрать Поле1 из Таблица2)» заменить на «ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таблица2 По Таблица1.Поле1 = Таблица2.Поле1«

Популярность: 15%

Рубрика: Настройка и оптимизация | Метки: | Оставить комментарий

История изменений объектов в конфигурации «Управление торговлей 3.0 для РБ»

Приветствую Вас, дорогие читатели.

В процессе работы с конфигурациями 1С иногда возникает потребность знать кто и что изменил в конкретном документе или справочнике. В младших версиях конфигураций «1С предприятие 8» (Управление торговлей 10.3, Бухгалтерия 2.0, Бухгалтерия 1.6 для РБ и т.д.) стандартными средствами можно было получить только кто последний работал с документом или справочником, для этого использовался «журнал регистрации«. На примере конфигурации «Управление торговлей 3.0 для РБ» я хочу рассмотреть встроенный механизм версионирования (история изменений). Данный механизм используется во всех конфигурациях, созданных на базе БСП (библиотека стандартных подсистем), — Управление торговлей 11, Бухгалтерия 3.0, УНФ 1.3 и т.д.

Для включения версионирования необходимо в разделе «Администрирование — Общие настройки» включить признак «Версионирование объектов«.

Включить версионирование

Чтобы настроить объекты для версионирования необходимо выбрать команду «Версионируемые объекты», которая находится возле включения функционала версионирования.

Настройка списка объектов версионирования

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

  • Не версионировать — версии не сохраняются
  • Версионировать при записи — версии сохраняются при каждой записи объекта а базу.
  • Версионировать при проведении — настройка применяется только для документов и версии сохраняются только при проведении.

Для примера выберем для справочника «Номенклатура» вариант версионирования «Версионировать при записи«, а для документа «Заказ поставщику» — «Версионировать при проведении«.

Перейдем в список «Номенклатуры» и изменим несколько раз какой-нибудь элемент. В окне нашего измененного элемента на панели навигации формы нажмем на пункт «История изменений».

Отчет по изменениям

Выделим все позиции и нажмем кнопку «Отчет по изменениям». Откроется отчет по изменениям версий объекта. Здесь видно, что пользователь «Федоров» изменил реквизит «Наименование полное«.

Можно также посмотреть конкретную версию элемента справочника «Номенклатура«. Для этого необходимо выделить нужную нам версию и нажать кнопку «Открыть версию объекта«.

Открыть версию объекта

Еще можно перейти на любую сохраненную версию объекта. Но это касается только самого объекта, к регистрам и другим объектам, зависящим от нашего объекта, это не имеет отношения. Для этого выделим строку с необходимой нам версией и нажмем кнопку «Перейти на версию«.

Переход на версию объекта

В окне «История изменений» появится третья строчка с комментарием «Объект восстановлен из версии № 1 от 13.02.2013 22:47:30«, а также сообщение об успешном восстановления объекта.

Вроде и все. Как видите ничего сложного.

Популярность: 11%

Рубрика: Торговля 3.0 для РБ | Метки: | Оставить комментарий

Настройка нового обмена в конфигурации «Управление торговлей 11»

Приветствую Вас, дорогие друзья.

В сегодняшней статье я хочу описать процесс настройки нового обмена в конфигурации «Управление торговлей 11». Хочу сказать, что данный порядок действий можно отнести ко всем новым конфигурациям, которые основаны на БСП: Управление торговлей 3.0 для РБ, Бухгалтерия предприятия 3.0, Управление небольшой фирмой 1.4.

Все действия будем рассматривать на примере.

Пример.

Необходимо организовать онлайн обмен между конфигурацией «Управление торговлей 11» и базой «Тест».

Приступим к реализации.

1. Создадим новый план обмена «ОбменТестУправлениеТорговлей11».

Добавление нового плана обмена

2. Настраиваем состав плана обмена.

ВАЖНО! Для всех объектов авторегистрация ЗАПРЕЩЕНА. В составе обязательно должен быть регистр сведений «СоответствияОбъектовИнформационныхБаз».

Настройить состав плана обмена

3. Настраиваем модуль менеджера созданного плана обмена «ОбменТестУправлениеТорговлей11» (В модуль менеджера плана обмена
переносим код из плана обмена
«_ДемоОбменСБиблиотекойСтандартныхПодсистем»
демо-базы «БСП 2.1.2» либо если нет «БСП», то из любого подходящего плана обмена УТ 11). Модуль менеджера для нашего тестового плана обмена можно взять здесь.

4. Редактируем общие команды конфигурации. В параметр добавляем созданный план обмена. Необходимо отредактировать следующие команды:

  • ВыполнитьОбменДанными
  • ВыполнитьОбменДаннымиИнтерактивно
  • ОткрытьПравилаКонвертацииОбъектов
  • ОткрытьПравилаРегистрацииОбъектов
  • ОткрытьСценарииОбменовДанными
  • ОткрытьПравилаСинхронизацииДанных (Если такая команда есть, т.к. она добавилась в последних версиях)
  • ПерейтиВЖурналРегистрацииСобытийВыгрузкиДанных
  • ПерейтиВЖурналРегистрацииСобытийЗагрузкиДанных
  • ПолучитьНастройкиОбменаДаннымиДляВторойИнформационнойБазы

Настройка общих команд

5. Добавляем необходимые подписки на события:

  • ОбменДаннымиОбменТестУправлениеТорговлей11ЗарегистрироватьИзменение.  Данная подписка будет регистрировать изменения справочников. Настройки подписки:
  1. Источник подписки — справочники, участвующие в обмене.
  2. Событие — ПередЗаписью.
  3. Обработчик — обработчик данной подписки необходимо разместить в общем модуле «ОбменДаннымиСобытияУТ» с кодом ОбменДаннымиСобытия.МеханизмРегистрацииОбъектовПередЗаписью(» ОбменТестУправлениеТорговлей11″, Источник, Отказ).
  • ОбменДаннымиОбменТестУправлениеТорговлей11ИзменениеДокумента.  Данная подписка будет регистрировать изменения документов. Настройки подписки:
  1. Источник подписки — документы, участвующие в обмене.
  2. Событие — ПередЗаписью.
  3. Обработчик — обработчик данной подписки необходимо разместить в общем модуле «ОбменДаннымиСобытияУТ» с кодом ОбменДаннымиСобытия.МеханизмРегистрацииОбъектовПередЗаписьюДокумента(» ОбменТестУправлениеТорговлей11«, Источник, Отказ);
  • ОбменДаннымиОбменТестУправлениеТорговлей11ЗарегистрироватьУдаление.  Данная подписка будет регистрировать удаление документов, справочников. Настройки подписки:
  1. Источник подписки — документы, справочники, участвующие в обмене.
  2. Событие — ПередУдалением.
  3. Обработчик — обработчик данной подписки необходимо разместить в общем модуле «ОбменДаннымиСобытияУТ» с кодом ОбменДаннымиСобытия.МеханизмРегистрацииОбъектовПередУдалением(» ОбменТестУправлениеТорговлей11«, Источник, Отказ);
  • ОбменДаннымиОбменТестУправлениеТорговлей11ЗарегистрироватьИзменениеНабораЗаписей. Данная подписка будет регистрировать  изменения регистров накопления, сведений, бухгалтерии, расчетов. Настройки подписки:
  1. Источник подписки — наборы записей регистров, необходимых для регистрации изменений.
  2. Событие — ПередЗаписью.
  3. Обработчик — обработчик данной подписки необходимо разместить в общем модуле «ОбменДаннымиСобытияУТ» с кодом ОбменДаннымиСобытия.МеханизмРегистрацииОбъектовПередЗаписьюРегистра(» ОбменТестУправлениеТорговлей11«, Источник, Отказ)

6. Добавим общую команду «ПомощникНастройкиОбменаДаннымиСТестом«. Данная команда необходимо для реализации помощника обмена.

В обработчик команды необходимо добавить код: ОбменДаннымиКлиент.ОткрытьПомощникНастройкиОбменаДанными(» ОбменТестУправлениеТорговлей11«)

7. В общий модуль «ОбменДаннымиПереопределяемый»
в процедуру «ПолучитьПланыОбмена» добавить наш план обмена
ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена.ОбменТестУправлениеТорговлей11)Общий модуль "Обмен данными переопределяемый"

8. Создаем макет плана обмена «ОбменТестУправлениеТорговлей11«
«ПравилаКонвертации» (тип — ТекстовыйДокумент) и загружаем
в это макет правила, созданные с помощью КонвертацииДанных.

9. Если необходимо, добавляем правила регистрации. Чтобы использовать правила регистрации необходимо добавить произвольную форму плана обмена «ФормаНастройкиУзла», макет «ПравилаРегистрации», в модуле менеджера плана обмена отредактировать процедуры «НастройкаОтборовНаУзле» и «ОписаниеОграниченийПередачиДанных«. В реквизиты формы «ФормаНастройкиУзла» добавить реквизиты, имена которых аналогичны именам реквизитов плана обмена, которые предназначены для фильтрации данных. Например «Организация», «Склад.»

Для примера «ФормуНастйрокиУзла» можно взять в плане обмена «ОбменУправлениеТорговлейБухгалтерияПредприятия30» и отредактировать под наши критерии.

10. В предприятии ПравилаКонвертации и ПравилаРегистрации необходимо ВСЕГДА загружать в регистр сведений «ПравилаДляОбменаДанными», для этого существует специальная форма для загрузки.

Для загрузки правил конвертации  необходимо в форме обменов выбрать «Настройки — Изменить«. Затем в форме плана обмена выбрать «Параметры обмена данными — Открыть правила конвертации объектов«. В форме редактирования правил конвертации по кнопке «Загрузить» загружаем привила либо из файла либо из макета определенного в п.8.

Загрузка правил конвертации и регистрации

Популярность: 35%

Рубрика: Торговля 3.0 для РБ | Метки: | 47 комментариев

Расчет начисления методом «От обратного» в конфигурации «Зарплата и управление персоналом 2.5»

Приветствую Вас, читатели блога.

В данной статье я хочу рассмотреть такой метод расчета в конфигурации «Зарплата и управление персоналом 2.5» как метод «От обратного». Метод «От обратного» — это когда известна конечная сумма, которую мы должны выдать сотруднику, и нам необходимо рассчитать начисления чтобы получить данный результат.

Рассмотрим пример.

Сотрудник «Иванов Иван Иванович» работает водителем. Оплата труда по окладу. Ему необходимо выплатить на руки 45000 р. Исходя из этой суммы надо сделать расчет по сотруднику.
Пойдем по пунктам.

1. Настройки программы. Если не включен признак «Управленческий учет», то необходимо его включить.

Настройки работы с программой

2. Затем в параметрах учета на закладке «Управленческий учет» указать валюту упр. учета,  например рубли.

Параметры учета программы

3. Затем в документе «Начисления зарплаты сотрудникам» укажем сумму, которую сотрудник должен получить на руки. Период начисления и месяц начисления в документе лучше задать начало года. Данный документ можно открыть в полном интерфейсе или в интерфейсе «Расчеты с персоналом» далее меню «Расчеты с персоналом», пункт «Начисление зарплаты сотрудникам»

Путь к документу.

Начисление зарплаты упр.

4. Создадим основное начисление, например «Доплата (метод от обратного)». Укажем способ расчета «Доначисление по управленческому учету», последовательность расчета — «Зависимое пятого уровня». У меня в демо-базе было 4 уровня зависимости, чтобы работал расчет необходимо создать еще одинВид начисления.

5. С помощью документа «Постоянные начисления, удержания» добавим данный вид расчета для сотрудника «Иванов Иван Иванович»

Документ "Постоянные начисления".

6. Подготовительный этап закончен можно приступать к расчету. Выберем в документе «Начисление зарплаты сотрудникам организаций» сотрудника «Иванов Иван Иванович» и нажмем кнопку «Рассчитать — Рассчитать (полный расчет)».

Док. Начисление регламентированной зарплаты

Получили итоговую сумму 45000, которую должны были рассчитать.

Популярность: 8%

Рубрика: Расчеты с персоналом | Метки: | Оставить комментарий