Именно 13-го июня в первый рабочий день база и слетела. Прямо с утра. При запуске пишет: «Файл базы данных поврежден. 1cv8.1CD» и все тут. Ни в конфигуратор ни в предприятие не пускает.
Последний бэкап понятно как обычно старый, ибо при последнем обновлении 1С рабочую базу перенесли в другую папку, которая соответственно в архив не попадала.
В общем вот исходные данные:
1. 1С 8.2.14.540
2. убитый файл 1Сv8.1CD весом 900 МБ датой от 12.06.2012;
3. рабочий файл 1Сv8.1CD весом 900 МБ датой от 26.04.2012;
На уровне подсознания понятно что из этого что то можно получить но пока не ясно как.
СЛАВА ИНТЕРНЕТУ!!! ИНФОРМАЦИЯ - вот в чем его сила. И пока, но все меньше, свободная (лирическое отступление).
По сути вопроса в Сети достаточно много информации, но все в итоге сводится к махинациям с копированием части исправного файла в убитый. Главный инструмент в данном случае - программка tool_1CD. Огромное спасибо ее автору Валерию (awa)!. Так же очень полезна статья того же автора: Краткое описание формата файлов *.1CD (файловых баз 1Сv8) . Ее пожалуй нужно прочитать перед началом попытки восстановления, тогда понятнее станет что и как делать.
ИТАК:
Первым делом конечно нужно скопировать оба файла (убитый и целый) куда нибудь подальше чтобы не потерять их исходники. Там мы их не трогаем. Затем скопировать их еще раз в папку где будем проводить эксперименты. Вот тут пожалуйста - издеваемся над ними как хотим ).
Еще до поиска в Сети пришла в голову мысль воспользоваться стандартной утилитой 1С CHDBFL.EXE для проверки и исправления файла базы.
После исправления этой утилитой 1С при загрузке стала ругаться на отсутствие таблицы _SYSTEMSETTINGS и кроме того размер файла базы сократился в 2 раза до 450 МБ. Очень странные результаты - хотя по отзывам данная утиль довольно грубая и помогает далеко не всегда, а иногда и усугубляет ситуацию (.
Ладно, заменяем жертву эксперимента файлом из «резервного хранилища».
Теперь читаем статью по формату 1Cv8.1CD и проникаемся. Ага, теперь более-менее понятно для чего и как можно использовать программу tool_1CD. Запускаем 2 экземпляра:
1.с убитым файлом:
2. с целым файлом:
Блин, ну сразу видно что 4-х таблиц не хватает. Каких -легко определить ибо порядок размещения одинаков. Таким образом у меня порушились:
- _SYSTEMSETTINGS;
- _COMMONSETTINGS;
- _REPSETTINGS;
- _FRMDTSETTINGS.
Тут я понял что дело не так уж плохо - ведь пропали только системные таблицы, которые по логике вещей и не изменились с последнего бэкапа. Ура!!!!!. Но тут конечно кому как повезет(((.
Ну вот теперь мы знаем что файл 1Cv8.1CD структурирован и хранит в себе описание и содержимое всех таблиц, а в начале файла есть основная секция где указано размещение этих таблиц.
Тут нам без HEX-редактора не обойтись. А сейчас что-то мало бесплатных то ((((. А у меня еще с давних темных времен припасена коллекция редакторов и дебаггеров. Уж и не помню для чего)))).
Ну все - запускаем HEX-Assistant и снова открываем в нем оба наших подопытных файла:
Для тех, кто внимательно прочитал статью не секрет, что блок, где хранится размещение таблиц №2 и найти его можно по смещению 0х4000:
Вот она, вот она рыба моей мечты !!! . В tool_1CD таблицы расположены в том же порядке что и в файле пэтому мы легко находим смещения для недостающих у наc таблиц:
_SYSTEMSETTINGS = 0x0000E61C
_COMMONSETTINGS = 0x0000E65C
_REPSETTINGS = 0x0000E66F
_FRMDTSETTINGS = 0x0000E683
Так же видим что смещения одинаковы в обоих файлах. Это значит, что все вообще просто:
1. идем по указанному смещению в целом файле;
2. выделяем полностью фрагмент кода с начального смещения данной таблицы до начального смещения следующей;
3. копируем с заменой в убитый файл точно на те же адреса.
4. сохраняем изменения в бывшем убитом файле.
5. проверяем tool_1CD что таблицы появились. Прога ругаться может на индексы, но они после восстановятся.
6. (по своему усмотрению) прогоняем утилитой CHDBFL.EXE (она там поругается немного, можно не обращать внимания).
или
запускаем конфигуратор - тестирование и исправление
или
делаем выгрузку-загрузку.
Я на всякий случай сделал все .
Все. Время принимать поздравления и обещания расцеловать от бухгалтерии и наставления от начальства по поводу необходимости ежедневного архивирования. В который раз ))))).
Bell в управляемом интерфейсе пробует сохранить выбранные картинки в базу 1С, но возникли сложности с сохранением в хранилище значений. как пример Bell приложил CF файл с мини конфигурацией, за что ему большое спасибо, т.к. большая часть материалов этой статьи написана им, я лишь поправил небольшие участки кода связанные с передачей файлов и сохранение в хранилище значений.
Так как везде уже Такси, то CF я перевел в этот режим и в нем демонстрирую.
Имеется справочник Хранилище данных:
Основная Форма Элемента:
Ее код:
так же имеется общая форма ФормаЗагрузкиФайлов
При помощи ее выбираются файлы изображений и загружаются в справочник - одновременно можно загружать несколько файлов
код формы:
в коде вызывается ОповеститьОВыборе(ПомещенныеФайлы) и срабатывает обработчик в ФормаСпискаДополнительно
и следующим кодом идет создание элементов справочника и загрузка изображений из временного хранилища
При работе с регистрами расчета есть возможность получения базовых данных. Это своеобразный способ расчета оборотов регистра, при котором функция расчета оборотов не является простой функцией суммирования ресурсов регистра по измерениям за определенный период, а представляет собой более сложную функцию. Эта функция зависит от состояния плана видов расчета, назначенного регистру расчета и, таким образом, управляется пользователем.
В данном разделе мы рассмотрим два существующих в системе способа получения базовых данных - при помощи языка запросов и при помощи функциональной записи, методом ПолучитьБазу(). При этом будет называть "основным" регистром расчета тот регистр, для которого необходимо получить базовые данные, а "базовыми" регистрами (которых в общем случае может быть несколько) будем называть те регистры, для которых выполняется суммирование ресурсов.
Мы не будем рассматривать эти способы подробно, рассмотрим только их отличия и область применения.
Метод ПолучитьБазу()
Метод ПолучитьБазу() определен для объектов РегистрРасчетаМенеджер.<Имя регистра расчета> и РегистрРасчетаЗапись.<Имя регистра расчета>. Метод позволяет задать ресурсы базовых регистров, по которым необходимо получить обороты, задать поля, в разрезе которых нужно получить обороты и задать правила сопоставления измерений основного и базовых регистров расчета.
Правила сопоставления записей регистров расчета задаются структурой, каждый элемент которой задает для того или иного измерения основного регистра список измерений базовых регистров расчета. Имена элементов структуры должны совпадать с именами измерений основного регистра, а значения элементов структуры - строки, со списком измерений базовых регистров через запятую. Если элемент структуры с именем того или иного измерения не задан, то это значит, что на соответствующее измерение не налагается условие.
Имена измерений и ресурсов базовых регистров задаются в формате <ИмяРегистраРасчета>.<ИмяПоля>.
Пример использования метода:
В приведенном выше примере измерение "Физлицо" основного регистра при получении оборотов будет сопоставляться с измерением "Физлицо" базового регистра "ОсновныеНачисления" и измерением "Работник" базового регистра "ДополнительныеНачисления".
Таблица языка запросов для получения базовых данных
Для получения базовых данных в языке запросов определены виртуальные таблицы "РегистрРасчета.<Имя регистра расчета>.База<Имя базового регистра расчета>". В качестве параметров виртуальной таблицы задаются измерения основного регистра, измерения базового регистра и поля, в разрезе которых нужно получить базовые данные. Измерения и разрезы задаются как массив (или список значений) строк с именами измерений.
Пример написания запроса с использованием виртуальных таблиц базовых данных:
Приведенный пример предполагает ту же структуру данных и ту же решаемую задачу, что и пример для метода ПолучитьБазу(). При этом мы видим заметное увеличение исходного кода и кажущуюся его сложность.
Сравнение
Заметным отличием функционального метода получения базовых данных и получения при помощи запроса является то, что в функциональном методе одним вызовом метода можно получить базовые данные по всем базовым регистрам, а при использовании запросов получение базовых данных делается запросом к нескольким таблицам - по числу базовых регистров. Тем не менее, рекомендуемым способом получения данных является получение данных запросом. Это позволит, например, получить не только данные базовых видов расчета, но и дополнительную информацию, необходимую для расчета.
Отметим, что производительность получения данных при помощи функционального метода и при помощи запроса одинакова несмотря на кажущееся усложнение исполняемого кода в случае с запросами.
Краткая функциональная запись с использованием метода ПолучитьБазу() допустима только в том случае, если нет необходимости в иных данных помимо базовых, и при этом хочется "сэкономить" на строках кода. Совершенно не допустимо из соображений производительности кода, применение метода ПолучитьБазу() в том случае, если после его использование все равно придется при помощи запроса получать дополнительные данные для расчета.
Еще одно соображение касается условий отбора базовых данных. Для метода ПолучитьБазу(), фактически, нет возможности получить базовые данные иначе, чем по одной записи или по конкретному регистратору (с отбором по тем или иным измерениям). В случае же запроса в распоряжении у разработчика все возможности языка запросов по отбору записей.
Обработка Универсальный обмен данными в формате XML (обработка универсальныйобменданнымиxml)
Обработка "Универсальный обмен данными в формате XML" предназначена для загрузки и выгрузки данных в файл из любой конфигурации, реализованной на платформе 1С:Предприятие 8.
Режим работы
При использовании управляемой формы обработка имеет два режим работы:
1. На клиенте. При использовании этого режима файлы правил и загружаемых данных передаются с клиента на сервер, а файл выгружаемых данных передается с сервера на клиент. Пути к этим файлам, находящимся на клиенте, необходимо указывать в диалоговом окне непосредственно перед выполнением действия.
2. На сервере. В этом режиме файлы не передаются на клиентн и пути к ним необходимо указывать на сервере.
Примечание: Файл внешней обработки и файлы протоколов обмена всегда должны находиться на сервере вне зависимости от режима работы.
Выгрузка данных
Для осуществления выгрузки данных необходимо указать имя файла, в который будет осуществляться выгрузка данных и выбрать файл правил обмена. Правила обмена для любых конфигураций могут быть настроены в специализированной конфигурации "Конвертация данных, редакция 2".
Для выгрузки документов и записей независимых периодических регистров сведений необходимо указать период - "Дату начала" и "Дату окончания". Результирующий файл с выгруженными данными может быть сжат.
На закладке "Правила выгрузки данных" можно выбрать те типы объектов, которые должны выгружаться, настроить отборы для выборки объектов, либо указать узел обмена данными, для которого нужно выгружать данные.
На закладке "Параметры выгрузки" можно указать дополнительные параметры выгрузки данных.
На закладке "Комментарий" можно написать произвольный текст-комментарий, включаемый в файл обмена.
Загрузка данных
Для осуществления загрузки данных необходимо указать имя файла, из которого будет осуществляться загрузка данных.
Есть возможность настроить загрузку данных в транзакции. Для этого необходимо взвести флажок "Использовать транзакции" и указать количество элементов в одной транзакции при загрузке.
"Загружать данные в режиме обмена (ОбменДанными.Загрузка = Истина)" – если флаг установлен, то загрузка объектов будет выполнятся с установленным признаком загрузки. Это означает, что при записи объектов в базу данных будут отключены все платформенные и прикладные проверки. Исключение составляют документы, которые записываются в режиме проведения или отмены проведения. Проведение и отмена проведения документа выполняется всегда без установки режима загрузки, т.е. проверки будут выполняться.
Дополнительные настройки
Закладка служит для детальной настройки выгрузки и загрузки данных.
"Режим отладки" – флаг для задания режима отладки обмена. Если этот флаг установлен, то процесс обмена данными не будет остановлен при возникновении какой-либо ошибки. Обмен завершится до конца с выводом отладочных сообщений в файл протокола обмена. Этот режим рекомендуется использовать при отладке правил обмена.
"Вывод информационных сообщений в окно сообщений" – если флаг установлен, то в окно сообщений будет выводиться протокол процесса обмена данными.
"Количество обработанных объектов для обновления статуса" – параметр служит для определения количества обработанных элементов перед изменением строки состояние загрузки/выгрузки
"Настройки выгрузки данных" – позволяют определить количество элементов обрабатываемых в одной транзакции при выгрузке данных, выгружать и обрабатывать только те объекты, на которые есть права доступа, настроить тип изменения регистрации для выгруженных объектов через планы обмена.
"Использовать оптимизированный формат для обмена данными (V8 - V8, версия обработки не ниже 2.0.18)" – оптимизированный формат сообщения обмена предполагает наличие узла "ИнформацияОТипахДанных" в заголовке сообщения, в который выгружается информация о типах данных. Это позволяет ускорить процесс загрузки данных.
"Использовать транзакции при выгрузке для планов обмена" – флаг определяет режим использования транзакций при выгрузке данных при выборке изменений на узлах планов обмена. Если флаг установлен, то выгрузка данных будет выполняться в транзакции.
"Количество элементов в транзакции" – определяет максимальное число элементов данных, которые помещаются в сообщение в рамках одной транзакции базы данных. Если значение параметра равно 0 (значение по умолчанию), то все данные помещаются в рамках одной транзакции. Такой режим является рекомендуемым, так как гарантирует согласованность данных, помещаемых в сообщение. Но при создании сообщения в многопользовательском режиме могут быть конфликты блокировок между транзакцией, в которой данные помещаются в сообщение, и транзакциями, выполняемыми другими пользователями. Для снижения вероятности возникновения таких конфликтов можно задать значение этого параметра, отличное от значения по умолчанию. Чем меньше значение параметра, тем меньше вероятность конфликта блокировок, но выше вероятность помещения в сообщение несогласованных данных.
"Выгружать объекты на которые есть права доступа" – если флаг установлен, то выборка объектов информационной базы будет выполняться с учетом прав доступа текущего пользователя программы. Это предполагает использование литерала "РАЗРЕШЕННЫЕ" в тексте запроса для выборки данных.
"Автоматически удалять недопустимые символы из строк для записи в XML" – если флаг установлен, то при записи данных в сообщение обмена недопустимые символы будут удалены. Символы проверяются на соответствие рекомендации XML 1.0.
"Изменения регистрации для узлов обмена после выгрузки" – поле определяет режим работы с регистрацией изменений данных после завершения выгрузки данных. Возможные значения:
Не удалять регистрацию – после выгрузки данных регистрация изменений на узле удалена не будет.
Полностью удалить регистрацию для узла обмена – после выгрузки данных регистрация изменений на узле будет полностью удалена.
Удалить регистрацию только для выгруженных метаданных – после выгрузки данных регистрация изменений на узле будет удалена только для объектов метаданных, которые были указаны к выгрузке.
"Протокол обмена" – позволяет настроить вывод информационных сообщений в окно сообщений, ведение и запись в отдельный файл протокола обмена.
"Имя файла, протокола обмена" – имя файла для вывода протокола процесса обмена данными.
"Протокол загрузки (для COM - соединения)" – имя файла для вывода протокола процесса обмена данными в базе-приемнике при обмене через COM-соединение. Важно: путь к файлу должен быть доступен с компьютера, на котором установлена база-приемник.
"Дописывать данные в протокол обмена" – если флаг установлен, то содержимое файла протокола обмена сохраняется, если файл протокола уже существует.
"Вывод в протокол информационных сообщений" – если флаг установлен, то в протокол обмена будут выводиться сообщения информативного характера, помимо сообщений об ошибках обмена.
"Открывать файлы протоколов обмена после выполнения операций" – если флаг установлен, то после выполнения обмена данными файлы протоколов обмена будут автоматически открыты для просмотра.
Удаление данных
Закладка нужна только для разработчиков правил обмена. Позволяет удалять из информационной базы произвольные объекты.
Отладка выгрузки и загрузки данных
Обработка позволяет совершать отладку обработчиков событий и генерировать модуль отладки из файла-правил или файла-данных.
Включение режима отладки обработчиков выгрузки производится на закладке "Выгрузка данных" установкой флажка "Режим отладки обработчиков выгрузки". Соответственно, на закладке "Загрузка данных" включение режима отладки загрузки производится установкой флажка "Режим отладки обработчиков загрузки".
После установки режима отладки обработчиков станет доступной кнопка настройки отладки. По нажатию на эту кнопку откроется окно настройки.
Настройка отладки обработчиков выполняется в четыре шага:
Шаг 1: Выбор режима отладки алгоритмов
На первом шаге необходимо определиться с режимом отладки алгоритмов:
Без отладки алгоритмов
Вызывать алгоритмы как процедуры
Подставлять код алгоритмов по месту вызова
Первый режим удобно использовать, когда мы точно знаем, что ошибка в обработчике не связана с кодом какого-либо алгоритма. В этом режиме код алгоритмов не выгружается в модуль отладки. Алгоритмы выполняются в контексте оператора "Выполнить()" и их код недоступен для отладки.
Второй режим необходимо использовать в тех случаях, когда ошибка находится в коде алгоритма. При установке этого режима алгоритмы будут выгружены как отдельные процедуры. В момент вызова алгоритма из какого-либо обработчика происходит обращение к соответствующей процедуре обработки. Этот режим удобно использовать, когда для передачи параметров в алгоритмы используется глобальная переменная "Параметры". Ограничения использования этого режима в том, что при отладке в алгоритме недоступны локальные переменные обработчика, из которого он вызывается.
Третий режим отладки используется, как и во втором случае, при отладке кода алгоритмов и в тех случаях, при которых второй режим отладки не подходит. При установке этого режима алгоритмы будут выгружены как интегрированный код в обработчиках. Т.е. взамен оператора вызова алгоритма вставляется полный код алгоритма с учетом вложенных алгоритмов. В этом режиме нет ограничений на использование локальных переменных обработчика, однако есть ограничение при отладке алгоритмов с рекурсивным вызовом.
Шаг 2: Формирование модуля отладки
На втором шаге необходимо произвести выгрузку обработчиков нажатием на кнопку "Сформировать модуль отладки выгрузки (загрузки)". Сформированные обработчики и алгоритмы будут выведены в отдельное окно для просмотра. Содержимое модуля отладки необходимо скопировать в буфер обмена нажатием на кнопку "Копировать в буфер обмена".
Шаг 3: Создание внешней обработки
На этом шаге необходимо запустить конфигуратор и создать новую внешнюю обработку. В модуль обработки необходимо вставить содержимое буфера обмена (модуль отладки) и сохранить обработку под любым именем.
Шаг 4: Подключение внешней обработки
На четвертом, завершающем шаге, надо указать имя файла внешней обработки в поле ввода. При этом программа выполняет проверку по времени создания (обновления) файла обработки. Если обработка имеет более раннюю версию, чем версия файла модуля отладки, то будет выведено предупреждение и форма настройки закрыта не будет.
Примечание: Возможность отладки глобального обработчика конвертации "После загрузки правил обмена" не поддерживается.
Программисту, имеющего немного опыта на платформе 1С 8.2, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта, а-а-а-а-аааа!!.....
Именно такое сложное чувство непонимания было поначалу и у меня. В процессе обучения и реального опыта была создана эта шпаргалка, целью которой было "разложить всё по полочкам", чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи объектов.
Для чего нам вообще нужны эти обработчики?
Очень часто программисту требуется переопределить стандартное поведение системы во время записи объектов, а именно: отменить запись, в случае каких-то условий; запросить дополнительную информацию у пользователя; дозаполнить реквизиты; что-то ещё записать в базу данных на основании этой записи; что-то изменить на форме после записи и т.д. и т.п. Каждый программист рано или поздно сталкивается с подобными задачами, потому знать назначение и последовательность запуска этих событий программисту, работающему на платформе 1С 8.2, необходимо.
В модуле формы или в модуле объекта?
Сначала надо определиться нужны ли нам данные формы? Будет ли запись записываться программным способом или только интерактивно? Будем ли вести диалог с пользователем?
Дело в том, что часть событий выполняется на уровне модуля формы и это значит, что они выполняются только при интерактивной записи, а также в этих событиях мы можем обращаться к данным формы, вести диалог с пользователем.
Другая часть событий выполняется на уровне модуля объекта, как при интерактивной, так и при программной записи.
Потому можно сразу определиться с обработчиком модуля формы или модуля объекта будем работать.
Модуль формы: на клиенте или на сервере?
Далее, если выбран модуль формы, то надо определиться какой обработчик потребуется: исполняемый на клиенте, или исполняемый на сервере. Если потребуется диалог с пользователем, то на клиенте, в противном случае на сервере. Их можно отличить по имени директивы компиляции или по имени обработчика (когда на сервере, это пишется в имени, например ПередЗаписьюНаСервере()).
Как выбрать конкретный обработчик?
Выбор зависит от поставленной задачи. Что конкретно можно делать в каждом обработчике опишу ниже, а пока пример.
Пример выбора обработчиков событий записи объекта:
Бывают задачи, когда потребуется использовать несколько обработчиков для решения одной задачи. Например, надо запросить информацию у пользователя во время записи: «Будем создавать новый документ на основании этой записи?» и, если пользователь ответит утвердительно, то надо создать новый документ с ссылкой на записываемый объект. Причем запись нового документа надо выполнять в транзакции, т.к. если текущая запись по каким то причинам будет отменена, то и уже созданный и записанный документ не должен остаться в базе данных.
Для решения этой задачи потребуется использовать обработчики события модуля формы по двум причинам:
1) Диалог с пользователем возможен только на клиенте, а клиентеские обработчики есть только в модуле формы. Для диалога будем использовать клиентскую процедуру модуля формы ПередЗаписью(), и сохраним ответ пользователя в параметре этой процедуры «ПараметрыЗаписи».
2) А в процедуре ПриЗаписиНаСервере() модуля формы примем этот параметр и в зависимости от него будем создавать документ или нет. Почему именно эта процедура? Ссылка будет получена только после записи, но поскольку нам нужно записывать в транзакции, то нужно использовать процедуры ДО завершения транзакции, но уже имеющие ссылку на записываемый объект. ПередЗаписью() не подходит , так как ещё нет ссылки, а ПослеЗаписи() не подходит, так как транзакция уже завершена. Остаётся ПриЗаписи(), но перед нами встаёт выбор: модуля формы или модуля объекта? Поскольку обработчик события ПриЗаписи() модуля объекта не содержит параметр, содержащий ответ пользователя, а событие ПриЗаписиНаСервере() модуля формы содержит, то ответ очевиден-используем это событие ПриЗаписиНаСервере() модуля формы потому что:
1) Это событие выполняется в транзакции 2) Содержит параметр «ПараметрыЗаписи», в котором уже содержится ответ пользователя, который передался из процедуры ПередЗаписью() 3) Ссылка уже создана и можно создавать новый документ, используя эту ссылку.
Ну и теперь последовательность запуска событий (в том порядке, в каком они перечислены) и небольшие подробности :
Во многих обработчиках есть параметр «Отказ». Там, где этот параметр присутствует означает, что в этом обработчике ещё можно отказаться от записи, присвоив параметру «Отказ» значение Истина, и тогда запись произведена не будет. 1) Модуль формы ПередЗаписью(Отказ, ПараметрыЗаписи)
Выполняется на клиенте!
Этот обработчик следует использовать, если необходимо организовать диалог с пользователем перед тем, как записать объект. Запросить дополнительную информацию, предупредить о чём-либо, дать возможность отказаться и т.п.
Второй параметр этого обработчика «ПараметрыЗаписи» имеет тип «Структура». У документов эти параметры заполняются системой предопределенными параметрами РежимЗаписи, РежимПроведения. Можно добавить свои.
Эти параметры передаются между событиями формы ПередЗаписьюНаСервере, ПриЗаписиНаСервере, ПослеЗаписиНаСервере, где их можно благополучно использовать. Например, при записи регистра сведений, надо сделать запись в другой регистр сведений старое значение ресурса. Можно передать старое значение в эти самые параметры и уже в ПриЗаписиНаСервере сделать запись в другой регистр. 2) Модуль формы ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)
3) Модуль объекта ОбработкаПроверкиЗаполнения (Отказ, ПроверяемыеРеквизиты)
Эти два обработчика проверки заполнения реализуются через параметр «ПроверяемыеРеквизиты» типа Массив, содержащий реквизиты, которые надо проверять (т.е. которым установлено свойство проверки заполнения «Выдавать ошибку»)
И если из этого массива убрать реквизит, то проверяться он не будет, если добавить, то будет выполняться проверка заполнения.
Таким образом, можно сказать, что эти два обработчика событий предназначены :
Для включения в проверку заполнения тех реквизитов, у которых в свойствах «ПроверкаЗаполнения» указано «Не проверять». Для этого надо добавить этот реквизит в массив параметр «ПроверяемыеРеквизиты»
Для того, чтобы исключить из автоматической проверки реквизиты, у которых установлено свойство проверки заполнения «Выдавать ошибку» в зависимости от каких-то условий. Для этого надо удалить этот реквизит из массива параметра «ПроверяемыеРеквизиты»
Имеется несколько особенностей, которые необходимо учитывать:
Если у формы из которой записывается объект в свойствах не установлено «ПроверятьЗаполнениеАвтоматически», то тогда эти обработчики проверки заполнения не вызываются и проверки не происходят!
Вызываются только при интерактивной записи! При программной записи не вызываются. Для проверки нужно использовать метод объекта ПроверитьЗаполнение(), который инициирует запуск этих событий.
Для документов, имеющих возможность проведения , эти события проверки заполнения вызываются только при проведении!
Оба эти события выполняются на сервере, отличие в том, что ОбработкаПроверкиЗаполненияНаСервере() это событие модуля формы и, следовательно, есть доступ к данным формы. А ОбработкаПроверкиЗаполнения() - событие модуля объекта. 4) Модуль формы ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
В этом обработчике можно дозаполнять реквизиты объекта или провести дополнительные проверки. Есть доступ к данным формы. Есть параметр ТекущийОбъект.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (СправочникОбъект,ДокументОбъект и т.д). Т.е. экземпляр класса объект создан, и можно обратиться к его свойствам и методам, но в базу данных ещё не записан. Начало транзакции 5) Модуль объекта ПередЗаписью(Отказ)
В этом обработчике можно дозаполнять реквизиты объекта или провести дополнительные проверки.
Для документов в параметры данного обработчика добавляются ещё два параметра:РежимЗаписи, РежимПроведения. Запись 6) Модуль объекта ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)
Возникает в момент, когда выполняется установка номера нового документа, задачи или бизнес-процесса.
Или ПриУстановкеНовогоКода(СтандартнаяОбработка,Префикс)
Возникает в момент, когда выполняется установка нового кода элемента справочника, узла плана обмена или кода плана видов характеристик.
Эти событии вызываются для объектов у которых указано свойство «Автонумерация» и только для новых объектов.
Если установить параметру СтандартнаяОбработка значение Ложь, то новый номер генерироваться не будет и можно программно задать код объекта в данном обработчике. 7) Модуль объекта ПриЗаписи(Отказ)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи.
Ссылка уже есть и можно записать в базу данных дополнительные данные на основании текущего объекта, используя эту ссылку.
Например, при записи создавать другой документ, содержащий реквизит ссылку на записываемый. 8) Модуль формы ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи. Есть доступ к данным формы. Есть последний шанс отказаться от записи.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (СправочникОбъект,ДокументОбъект и т.д). Можно обратиться к его свойствам и методам. Завершение транзакции 9) Модуль формы ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
Выполняется на сервере.
Можно использовать для того, чтобы визуально что-то отобразить на форме. 10) Модуль формы ПослеЗаписи(ПараметрыЗаписи)
Выполняется на клиенте!
Можно использовать для того, чтобы визуально что-то отобразить на форме или выдать предупреждение пользователю.
В этом материале подробная инструкция по настройке обмена РИБ для 1С:Предприятие 8 и проблемы, с которыми столкнулся автор.
1. Создание узлов
Создаем новые узлы (главный и подчиненный): в пользовательском режиме "Операции / Планы обмена/Полный" Выберем план обмена "Полный"
Создаем две записи:
- первую запись назовем "ЦБ" (главный узел), код укажем "ЦБ",
- вторую запись назовем "Подчиненный узел", код укажем "ПУ". Значек с зеленным кружком - "ЦБ" (главный узел)
Для подчиненного узла нажимаем на иконку "Создать начальный образ". (Потребуется монопольный доступ) Создать начальный образ
Далее в открывшемся окне заполняем параметры новой базы. По окончании нажимаем кнопку "Готово" Создание начального образа ИБ
Начнется создание начального образа подчиненного узла распределенной информационной базы, по окончании появится сообщение "Создание начального образа успешно завершено". Жмем кнопку "ОК".
Добавляем базу подчиненного узла в список баз, запускаем ее.
В этой подчиненной базе открываем полный план обмена - значок "ЦБ красный, это значит, что этот узел является главным для информационно базы, в которой мы находимся.
2. Настройка префиксов
Для каждой базы, в настройках параметров учета (в УПП "Сервис / Параметры учета") на закладке "Обмен данными", устанавливаем префиксы. Это делается для того чтобы не возникало конфликтов в номерах и кодах документов и справочников, созданных в двух базах.
Для автообмена, устанавливаем галочку "Использовать механизм автоматического обмена..." Закладка "Обмен данными"
3. Добавляем настройку обмена данными между узлами
Открываем: "Сервис \Распределенная информационная база (РИБ)\Настроить узлы РИБ"
Нажимаем "Добавить", откроется окно "Настройка обмена данными" Настройка обмена данными
Нажимаем на значок "Выполнить обмен по текущей настройке" Выполнить обмен по текущей настройке
Теперь о "подводных камнях"
1. Обмен данными может выполняться в автоматическом режиме и может быть инициализирован в следующих случаях:
* При запуске программы. Обмен будет выполняться при запуске программы,
* При завершении работы с программой. Обмен будет выполняться перед завершением пользователем работы с программой,
* При появлении каталога. Обмен будет выполнен только в том случае, если каталог указанный пользователем был невиден, а в настоящий момент стал виден. Настройка может быть использована для выполнения автоматического обмена при подключении к локальной сети или flash карты. Программа периодически будет проверять видимость указанного в настройках каталога и отмечать его текущее состояние,
* При появлении файла. Рекомендуется использовать данные режим, когда нужно выполнить обмен, если появляется входящий файл обмена данными. В этом случае, достаточно указать полный путь к входящему файлу обмена данными. Программа периодически анализирует наличие файла, и как только он появится, будет выполнен обмен, а после обмена этот файл будет принудительно УДАЛЕН (это делается для того, что бы процедура обмена не выполнялась постоянно),
* Периодический обмен данными. Обмен будет выполняться согласно настройкам периодического обмена данными. Если информационная база работает в файл-серверном режиме, то периодический обмен выполняется только у пользователя, который указан в параметрах учетной политики как "Пользователь для регламентных заданий в файловом режиме". В Клиент-серверном варианте обмен выполняется на сервере 1C:Предприятия.
У меня Клиент-серверный вариант - для работы регламентного автообмена пришлось перегружать сервер
2. Кодировка Windows.
Обмен прерывался ошибкой - так как не происходит сжатие файла. Это из-за ошибки кириллицы в командной строке при сжатии.
Лечится исправлением кодировок в реестре.
Например, для Windows Server 2008 -
3. Создавая копию базы (например, для доработки) в клиент-серверном варианте, НЕОБХОДИМО, чтобы РЕГЛАМЕНТНЫЕ ЗАДАНИЯ КОПИИ базы были ВЫКЛЮЧЕНЫ. Блокировка регламентных заданий для копии ВКЛ
Если их не заблокировать, то копия будет делать обмены по тому же расписанию, что и основная база. Значит, часть сообщений в удаленные узлы будет формироваться из рабочей базы, а часть из копии, что приведет рассинхронизации конфигураций. Источник
Нужно документ РеализацияТоваровУслуг (ссылка на который выбирается в диалоге создаваемой обработки) перенести в другую базу данных. Структура конфигураций идентична. Справочники (и другие сопутствующие объекты) синхронизированы по значениям внутренних идентификаторов.
Для выгрузки потребуется выполнить следующий фрагмент кода:
При выгрузке создаем элемент Root исходя из соображений, что в XML-документе должен быть только один корневой узел, а в общем случае (но не в нашем) выгружаться может не один объект.
Для загрузки выгруженного значения используем следующий фрагмент кода:
При работе с 1С:Предприятие 8.1 по некоторым независящим от нас с Вами причинам вы можете с толкнуться с сообщением об ошибке «Ошибка формата потока».
Например это может произойти так: После запуска chdbfl.exe выдал ошибки во внутреннем файле превышена длина кода, потом показал что ошибки исправлены. После этого запустить конфигурацию не удалось, стала выходить ошибка "ошибка формата потока......".
Способы возможного решения проблемы: * удаление из списка баз и повторное добавление
* очищение данных из каталога "C:\Documents and Settings\пользователь\Application Data\1C\1Cv81"
* простое копирование содержимого каталога bin в новый каталог
Общей причиной возникновения такой ситуации можно считать сбои железа (в одном случае пропала сеть, отключилось электричество), софта и т.д. (и не обязательно 1С).
* Отключите файрволы и антивирусы
* Скопировать базу с исходного источника другой флешкой
В случаи, если есть возможность зайти в режиме конфигуратора, то также есть смысл проверить целостность данных:
* для файловой версии использовать проверку целостности chdbfl.exe
* тестирование и исправление средствами конфигуратора
* выгрузка/загрузка конфигурации
Для ранних версий платформы были характерны механизмы, не контролирующие некорректное хранение данных, поэтому обратите внимание на такие решения как:
* обновили платформу до последней версии (но не просто обновлением, а удалением старой версии, и затем установкой новой)
* очистка журнала регистрации
* в клиент-серверном варианте сообщение "Ошибка формата потока" может возникнуть у клиента, когда одно из приложений из набора 1С:Предприятия, выполняющихся на сервере, не имеет достаточно дискового пространства в разделе /tmp для размещения временных файлов
* проверить обработкой все метаданным все строковые реквизиты (проверяем наличие и удаляем сивмолы 0x1a & 0xFFFF )
Особенно это характерно для ситуаций: после изменения типа реквизита формы справочника при попытке сохранить конфигурацию после долгого продолжительного молчания не приходя в сознание платформа выдала сообщение "ошибка формата потока".
Или в такой ситуации: Если через COMConnector происходит обращение к клиент-серверной базе данных, то возможной причиной ошибки является передача от клиента (COMConnector-а в клиентском приложении) серверу 1С:Предприятия или наоборот значения типа "Строка", содержащего символы с кодами 0x1F или 0xFFFF. Передача может выполняться как через параметры и результат процедур и функций, исполняемых на сервере, так и в том случае, если такие символы содержатся, например, в строковом значении константы.
Нужно документ РеализацияТоваровУслуг (ссылка на который выбирается в диалоге создаваемой обработки) перенести в другую базу данных. Структура конфигураций идентична. Справочники (и другие сопутствующие объекты) синхронизированы по значениям внутренних идентификаторов.
Для выгрузки потребуется выполнить следующий фрагмент кода:
При выгрузке создаем элемент Root исходя из соображений, что в XML-документе должен быть только один корневой узел, а в общем случае (но не в нашем) выгружаться может не один объект.
Для загрузки выгруженного значения используем следующий фрагмент кода:
Для 8.х: Как отключить узел от распределенной информационной базы?
Поскольку сама конфигурация заблокирована, то этот код надо создавать в обработке, открыв каую-нибудь другую (незаблокированную) конфигурацию, вставить кнопку в конфигураторе. Сохранить её как внешнюю обработку и выполнить, запустив базу в режиме 1С:Предприятие в монопольном режиме (и открыв внешнюю обработку из файла).
При этом, этот код нельзя выполнить в режиме отладчика, т.е./или имея конфигуратор открытым на отключаемой базе, поскольку требуется исключительная блокировка доступа к базе этого кода.
Название параметра не имеет значение, хотя по умолчанию, параметр процедуры для кнопки командной панели
будет проставляется как "Кнопка", а вставляемой через меню Форма --> Вставить элемент управления... подучается "Элемент"
Привожу тут код внешней обработки отключение - восстановление подключения к УРБД:
Для 7.7:
При преобразовании информационной базы в режим использования компоненты УРБД (Управление Распределенными Информационными Базами), в ИБ вносятся некоторые изменения, не позволяющие использовать базу в обычном режиме. А именно: добавляются три таблицы, отвечающие за процесс синхронизации, и вносятся изменения в таблицу 1ssystem.dbf Не забудьте сделать резервную копию перед тем, как: Удалить файлы 1sdbset.dbf, 1sdbset.cdx, 1sdwnlds.dbf, 1sdwnlds.cdx, 1supdts.dbf, 1supdts.cdx Удалить единственную запись из файла 1ssystem.dbf Зайти в режим конфигуратора, открыть, например, свойства конфигурации, добавить какой-нибудь символ в комментарий, а потом его удалить. После этого сохранить конфигурацию.
Опыт восстановления файловой базы 1Cv8.1CD 
.gif)