Файловые базы *.1CD. Физическая структура. Восстановление.

Как устроены файловые базы? Что делать, если база упала? В статье приведены обзорные сведения об устройстве баз и возможностях восстановления. Приведено описание новых возможностей Tool_1CD.

Предупреждение

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

 

Введение

Многие люди, работающие с программами 1С в файловом варианте, рано или поздно сталкиваются с такой проблемой, как неработоспособность файловой базы 1С.

Еще совсем недавно информации о способах восстановления в интернете было крайне мало. Вот, например, одна из самых известных статей на эту тему Методика восстановления разрушенных баз 1С:Предприятие 8 Вячеслава Гилева. Все описанные там способы относятся, в основном, к серверным базам данных. Про файловые базы данных там есть 2 совета: попробовать chdbfl.exe и отослать базу в 1С.

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

Восстановление файловой версии базы данных *.1CD после ошибки динамического обновления.

Восстановление работоспособности базы 1С 8.1 (файловой)

Опыт по восстановлению файловой версии базы после неудачной реструктуризации таблиц

Восстанавливаем убитую базу 1C

Большинство советов в таких статьях напоминают шаманские пляски с шестнадцатеричным редактором, и, как правило, применимы только в узких, специальных случаях.

Но в последнее время дело начало сдвигаться с мертвой точки. Сначала появился проект Дмитрия Воробьева (vde69) restoration-base-1c8 и его статья Как я востанавливал базу 1CD.

А совсем недавно появился цикл статей Андрея Савкина (andrewks)

Восстановление работоспособности файловой базы. 0. Введение

Восстановление работоспособности файловой базы. 1. Обследование

Восстановление работоспособности файловой базы. 2. Лечение

Восстановление работоспособности файловой базы. 3. Конфигурация

Очень рекомендую ознакомиться с ними. Впервые появился системный подход к процессу восстановления файловых баз 1С. Основой предлагаемых Андреем Савкиным способов лечения является его Компонента для прямого чтения/записи данных из файлов баз данных .1CD.

И, тем не менее, публикаций про восстановление серверных баз намного больше, чем про восстановление файловых, а вопросов, наоборот, больше про восстановление файловых баз. В чем причина такого диссонанса? Ответ прост. Серверы баз данных (обычно это MS SQL сервер) обладают большим функционалом по поддержанию целостности и обслуживанию баз. К тому же они позволяют напрямую получить доступ к таблицам и записям, что позволяет анализировать и исправлять ошибки в базе. Соответственно, серверные базы ломаются реже, и чинятся проще. Файловый же вариант баз является закрытым форматом, средств работы с базами, кроме собственно программ 1С, до недавнего времени не было. Программы 1С не дают низкоуровневого доступа к базе на уровне таблиц и записей. Программы 1С позволяют работать только с высокоуровневыми объектами конфигурации.

 

Стандартные средства восстановления

Что же нам предоставляет фирма 1С для восстановления файловых баз? Для этого есть инструмент «Тестирование и исправление» в конфигураторе и утилита «chdbfl.exe». Инструмент «Тестирование и исправление» предназначен для выявления и исправления логических ошибок в данных, но не для проверки физической структуры базы. Да и для того чтобы воспользоваться тестированием и исправлением, необходимо войти в конфигуратор. Но в подавляющем большинстве случаев о том, что есть проблемы с базой, люди узнают только тогда, когда база перестает работать совсем, и зайти ни в конфигуратор, ни в предприятие не получается.

Для проверки и восстановления физической структуры файловых баз 1С предлагает нам только утилиту «chdbfl.exe». Ее интерфейс скромен до аскетичности. Все настройки поведения этой утилиты заключены в одной галке «Исправлять обнаруженные ошибки». К сожалению, утилита «chdbfl.exe» обнаруживает далеко не все ошибки, и более того, иногда делает только хуже. Алгоритм работы утилиты в режиме исправления относительно прост. Она читает все данные из файла базы, которые может прочитать, и записывает их в новый файл базы. По окончании старый файл базы утилита удаляет! Без предупреждения. В результате, все данные, которые потенциально есть в битой файловой базе, бесследно исчезают! Желающие могут провести простой эксперимент. Возьмите копию любой непустой базы (обязательно копию! база будет потеряна!), посмотрите на размер файла базы. Исправьте любым шестнадцатеричным редактором в файле 1Cv8.1CD два байта по адресу 0x4020 на нули.

 Рушим базу

А теперь выполните проверку файла базы утилитой «chdbfl.exe» с установленным флажком «Исправлять обнаруженные ошибки» и посмотрите на размер базы данных. От всей базы вдруг осталось всего 20 килобайт! А утилита «chdbfl.exe» меж тем сказала «Ошибок не обнаружено». Она просто молча удалила всю базу целиком, в базе не осталось ни одной таблицы.

Конечно, это искусственный пример. Те два байта, которые мы обнулили – это на самом деле количество таблиц в базе. Утилита «chdbfl.exe» попыталась считать данные, обнаружила, что в базе 0 таблиц, и именно столько таблиц перенесла в новый файл базы. Но, если до применения утилиты «chdbfl.exe» были все шансы восстановить базу, ведь на самом деле все данные реально содержались в файле базы, то после применения утилиты восстанавливать просто нечего. Этот пример показывает, как себя ведет утилита «chdbfl.exe» в случае, если не может прочитать какие-то данные. Она их просто удаляет! В реальности, я неоднократно сталкивался со случаями, когда «chdbfl.exe» частично удаляла данные. Не всю базу, конечно.

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

Надеюсь, я смог вас убедить никогда не запускать «chdbfl.exe» с флажком «Исправлять обнаруженные ошибки», не сделав предварительно копию базы. Я отнюдь не призываю вообще не пользоваться «chdbfl.exe», но делать это надо с осторожностью!

Итак, мы выяснили, что существующих стандартных средств восстановления работоспособности файловых баз явно недостаточно. Поэтому приходится искать другие способы восстановления. А для этого очень помогут знания о внутреннем устройстве файловых баз.

 

Структура файла базы данных 1CD

Техническое описание внутреннего устройства опубликовано мной в статье Краткое описание формата файлов *.1CD (файловых баз 1Сv8). Однако она достаточно сумбурна, плоха для восприятия, поэтому здесь я попытаюсь описать формат немного более популярно. Чтобы не было путаницы с термином «файл», сразу замечу, что когда я буду иметь в виду файл базы *.1CD, я буду говорить «файл базы», когда же я буду говорить про внутренние файлы, содержащиеся внутри базы, я буду употреблять просто термин «файл».

Страницы

На самом нижнем уровне файл базы данных 1CD состоит из страниц размером 4 килобайт (0x1000).

Страницы

 

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


Файлы

На более высоком уровне находятся файлы. Файл состоит из одной или более страниц. У каждого файла есть ровно одна заголовочная страница, в которой размещается массив номеров страниц размещения. В каждой странице размещения, в свою очередь, находится массив номеров страниц данных. Заголовочная страница и страницы размещения – это служебные страницы, которые нужны только для хранения служебных данных (сигнатура, длина файла, версия) и для нахождения страниц данных. Собственно содержимое файла хранится в страницах данных.

Файл

Файл адресуется с помощью номера его заголовочной страницы. Страницы, принадлежащие одному файлу, совсем не обязаны следовать друг за другом, они могут быть разбросаны по всей базе. Если файл имеют нулевую длину, то у него есть только заголовочная страница. Если же файл содержит хотя бы 1 байт данных (имеет длину 1), у файла уже есть три страницы – заголовочная, одна страница размещения и одна страница данных, в которой и записан это байт.

 

Таблицы

Ну, а на самом высоком уровне находятся таблицы. Каждая таблица состоит из нескольких файлов:

  • файла описания таблицы DESCR;
  • файла записей DATA;
  • файла индексов INDEX;
  • файла данных неограниченной длины BLOB.

Таблица

Файл описания таблицы DESCR содержит текстовое описание таблицы – имя таблицы, состав полей и индексов. А также файл DESCR содержит номера файлов DATA, INDEX и BLOB. Таблица адресуется с помощью файла описания таблицы. Структуру файлов таблиц мы в данной статье рассматривать не будем, подробности можно узнать из моей статьи, ссылку на которую я приводил выше. Файл индексов может отсутствовать, если в таблице нет ни одного индекса. Файл данных неограниченной длины тоже может отсутствовать, если в таблице нет ни одного поля с данными неограниченной длины.

Адресация

Повторим еще раз. База состоит из таблиц. Таблицы, в свою очередь, состоят из файлов. И наконец, файлы состоят из страниц. Адресом страницы является ее порядковый номер (индекс) в файле базы. Адресом файла является номер его заголовочной страницы. Адресом таблицы является адрес ее файла описания, а значит, номер заголовочной страницы файла описания. Т.е. о каком бы объекте мы бы не говорили – странице, файле или таблице, адресом объекта всегда является просто номер страницы.

Предопределенные объекты.

Но каким образом найти нужную нам таблицу или файл? Как узнать их адрес? В базе есть предопределенные объекты с адресами 0, 1 и 2. Нулевая страница (страница с адресом 0) располагается в самом начале файла базы. Нулевая страница не принадлежит никакому файлу или таблице. Она содержит сигнатуру базы, версию структуры базы и длину базы в страницах. Предопределенный объект с адресом 1 – это специальный файл, содержащий все свободные страницы базы. Файл свободных страниц не принадлежит никакой таблице. И наконец, предопределенный объект с адресом 2 – это корневой файл. В корневом файле содержатся код локализации, количество таблиц в базе и список адресов всех таблиц. Корневой файл также не принадлежит никакой таблице.

Теперь мы можем ответить на вопрос, каков минимальный объем базы? Если база абсолютно пуста и в ней нет ни одной таблицы, то в файле базы все равно есть предопределенные объекты:

  • Нулевая страница;
  • Файл свободных страниц. Так как в пустой базе этот файл пустой, то он содержит только заголовочную страницу;
  • Корневой файл. В пустой базе этот файл не нулевой длины – в нем содержится код локализации и количество таблиц. Поэтому состоит из трех страниц – заголовочной страницы, одной страницы размещения и одной страницы данных.

Итого 5 страниц по 4 килобайта – 20 килобайт. Именно такой размер мы получили в эксперименте с chdbfl.exe, описанном выше.

 

Структура информационной базы 1С

Теперь рассмотрим вкратце, что нам надо знать про логическую структуру базы 1С. Определимся сначала с терминологией.

Информационная база 1С (файл 1Cv8.1CD) является файловой базой. Но не всякая файловая база является информационной базой 1С. Например, хранилище конфигураций (файл 1Cv8ddb.1CD), тоже является файловой базой, но не является информационной базой 1С.

Проще говоря, файловая база – это любой файл с расширением 1CD, а информационная база 1С – это частный случай файловой базы (с именем 1Cv8.1CD), в которой содержатся конфигурация и бизнес-данные. Тем не менее, когда говорят, что упала файловая база, практически всегда имеют в виду именно информационную базу.

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

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

Основа базы – это конфигурация, а конкретно конфигурация базы данных. От нее зависит, сколько в базе будет таблиц данных, какая у них будет структура. Конфигурация базы данных хранится в системной таблице CONFIG.

Основная (разрабатываемая) конфигурация целиком в базе не хранится. В таблице CONFIGSAVE хранятся только отличия основной конфигурации от конфигурации базы данных. В рабочих базах, как правило, таблица CONFIGSAVE пустая (кроме момента обновления конфигурации базы). К основным системным таблицам относятся также таблицы FILES, PARAMS и DBSCHEMA.

Таблицы CONFIG, CONFIGSAVE, FILES и PARAMS имеют идентичную структуру и, по сути, являются хранилищами файлов. Таблица DBSCHEMA всегда имеет одно поле и одну запись, хранящую текстовый файл.

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

{dde2d899-fa84-4179-8fd3-b937d9c170b0,»Reference»,2639},{3d446961-2fb8-11d7-85a2-0050bae0a772,»Fld»,1296},{3d446962-2fb8-11d7-85a2-0050bae0a772,»Fld»,1297},{6e3d2ddf-e57f-4a32-8953-61054fb9ba62,»Document»,83},{3d446963-2fb8-11d7-85a2-0050bae0a772,»Fld»,1298},{3d446964-2fb8-11d7-85a2-0050bae0a772,»Fld»,1299},{3d446965-2fb8-11d7-85a2-0050bae0a772,»Fld»,1300},{3d446965-2fb8-11d7-85a2-0050bae0a772,»ByField»,1322},{f6cc1c3b-f8a3-414e-8eac-03ac1aca96f0,»Fld»,651},{fcb79a42-9ae1-4560-91e9-07fe9847a821,»Fld»,818},{3d446966-2fb8-11d7-85a2-0050bae0a772,»Fld»,1301},{6e2326bd-d5f8-44f4-ad8a-9cd5d294774c,»Enum»,113}, 

Каждый объект конфигурации имеет свой внутренний уникальный идентификатор, который и используется в записи DBNames. Также здесь указывается тип хранимого объекта и тот самый порядковый номер объекта. Имя объекта в базе формируется как символ подчеркивания плюс тип и плюс номер. Например, таблицы, которые описаны в приведенном примере, будут иметь имена «_Reference2639», «_Document83» и «_Enum113», а индекс будет иметь имя «_ByField1322». Вообще, по имени типа объекта можно понять, что это – поле, индекс, или таблица. Полями являются типы «Fld», «LineNo», «Turnover», «TurnoverDt», «TurnoverCt». Имена типов индексов начинаются на «By» («ByField», «ByOwnerField», «ByParentField», «ByProperty», «ByPropRecorder», «ByResource», «ByDim», «ByDims», «ByDimension», «ByDimensions», «ByDimRecorder»). Остальные типы являются таблицами. Причем типы «VT» и «ExtDim» являются подчиненными таблицами (табличными частями), и для получения полных имен этих таблиц надо впереди еще добавить имя таблицы объекта владельца, например «_Document199_VT5172».

Дополнительно, в DBNames хранятся строки, относящиеся к некоторым системным таблицам

{00000000-0000-0000-0000-000000000000,»SystemSettings»,2660},{00000000-0000-0000-0000-000000000000,»CommonSettings»,2661},{00000000-0000-0000-0000-000000000000,»RepSettings»,2662},{00000000-0000-0000-0000-000000000000,»RepVarSettings»,2663},{00000000-0000-0000-0000-000000000000,»FrmDtSettings»,2664},{00000000-0000-0000-0000-000000000000,»UsersWorkHistory»,2665},

Уникальный идентификатор в таких строках пустой, т.е. эти таблицы не описаны в конфигурации. Имена таблиц при этом не содержат порядковый номер, т.е. имена соответствующих таблиц «_SYSTEMSETTINGS», «_USERSWORKHISTORY» и т.д.

Таким образом, все системные таблицы можно условно разделить на основные системные таблицы, их имена не начинаются с символа подчеркивания и они не описаны в DBNames, и дополнительные системные таблицы, имена которых начинаются с символа подчеркивания, и они описаны в DBNames. По этому признаку к основным таблицам можно отнести таблицы «IBVERSION» и «V8USERS». Но в реальности эти 2 таблицы не обязательны, и 1С вполне может запуститься без них.

Тот факт, что нумерация существующих объектов сохраняется при реструктуризации, приводит к тому, что в базах с одной и той же конфигурацией имена таблиц и полей одних и тех же объектов конфигурации могут быть разными. Рассмотрим простейший пример. Например, мы создали новую конфигурацию, в ней создали один справочник с одним реквизитом. После обновления конфигурации БД получаем такую картину (я не привожу все записи, остальные записи – это системные таблицы):

{3a0fb211-7a5d-455b-b951-6884ee6046b6,»Reference»,7},{a277b45a-1475-42d7-a472-53a0f9ddcd86,»Fld»,8},

Теперь добавим еще один справочник с одним реквизитом, обновим:

{3a0fb211-7a5d-455b-b951-6884ee6046b6,»Reference»,7},{a277b45a-1475-42d7-a472-53a0f9ddcd86,»Fld»,8},{d76fc06e-4f02-4956-84a0-44e1f3fa5279,»Reference»,10},{7522b3ce-385c-49a8-b6c7-6d3da206e0c4,»Fld»,11}

А теперь выгрузим конфигурацию, и загрузим ее в новую базу. После обновления в новой базе:

{3a0fb211-7a5d-455b-b951-6884ee6046b6,»Reference»,7},{d76fc06e-4f02-4956-84a0-44e1f3fa5279,»Reference»,8},{a277b45a-1475-42d7-a472-53a0f9ddcd86,»Fld»,9},{7522b3ce-385c-49a8-b6c7-6d3da206e0c4,»Fld»,10},

Как видим, номера одних и тех же объектов разные. Все из-за разного порядка обновлений.

Также следует заметить, что в записи DBNames содержатся только нумерованные объекты. Например, там нет полей, соответствующих стандартным реквизитам (Код, Наименование у справочников, Номер у документов и т.д.).

Полная структура всех таблиц данных содержится в единственной записи таблицы DBSCHEMA. Тут описаны все таблицы данных со всеми полями (в том числе, соответствующие стандартным реквизитам) с типами хранения, именно так, как это лежит в базе. Например, если у нас есть реквизит составного поля, то DBNames ему будет соответствовать одна строка, а вот в DBSCHEMA уже будут содержаться все поля, необходимые для хранения всего спектра значений этого реквизита. Но в DBSCHEMA нет привязки к объектам конфигурации.

Стоит еще немного остановиться на хранении реквизитов составного типа. 1С создает отдельное поле для каждого примитивного типа, входящего в составной тип, а также отдельное поле для ссылочных значений. Это общеизвестно, и описано, например, в статье Составные типы — бесплатный сыр мышеловки производительности. Я хочу обратить только внимание, что в поле вида ссылки (имена таких полей заканчиваются всегда на «TREF»), которое существует, если в составном типе возможны несколько видов ссылок, хранится порядковый номер объекта конфигурации, полученный им при реструктуризации. Тот самый номер, который записан в DBNames. И, кстати, этот же номер можно увидеть в представлении битой ссылки. Например, если мы видим « (20:94b81c6f65428d5911e2a8bebc48d793)», то мы сходу можем определить, что это ссылка на объект конфигурации, имеющий номер 20 в DBNames.

Итак, 1С для работы с информационной базой сначала загружает конфигурацию из таблицы CONFIG, затем определяет номера объектов по записи DBNames, после этого из записи в DBSchema получает окончательный состав полей всех таблиц, и только после этого 1С получает возможность работать с таблицами данных информационной базы.

Именно поэтому 1С очень чувствительна к ошибкам в CONFIG, DBNames и DBSchema.

 

Так что же делать?

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

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

Для того чтобы определить что же не так с базой, еще раз посоветую цикл статей Андрея Савкина (andrewks). В этом цикле достаточно хорошо описаны методы диагностики.  В дополнение к рассмотренным там методам могу посоветовать инструменты на странице «Дополнительно» программы Tool_1CD «Проверка состава таблиц», «Тест формата потока», «Найти дубли таблиц», так как вместе с этой статьей я выложил новую версию Tool_1CD в публикации Tool_1CD. Программа просмотра файлов баз *.1CD (1Сv8.x). Описание этих инструментов смотрите в следующем разделе.

Если вы разберетесь, что не так в базе, то поймете и как это исправить. Но вот с помощью чего это сделать? Вариантов много. Начиная от шестнадцатиричного редактора. Свои инструменты предлагают Андрей Савкин (andrewks) и Дмитрий Воробьев (vde69). Я тоже предлагаю свой инструмент — Tool_1CD.

В Tool_1CD появилась возможность редактирования таблиц. Правда, пока этот функционал находится в стадии альфа-версии, он еще не отлажен. Тем не менее, теперь вы можете попробовать воспользоваться некоторыми советами, которые ранее были применимы только для серверных баз. Например, в некоторых случаях после сбоев при обновлении конфигурации базы данных, может помочь удаление записей-маркеров в таблице CONFIG «commit», «dbStruFinal», «dynamicCommit».

Также, как я уже сказал, в новой версии Tool_1CD я сделал доступной страницу «Дополнительно», содержащую некоторые инструменты, которые могут пригодиться и для диагностики, и для восстановления баз.

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

 

Описание дополнительных инструментов Tool_1CD

Tool_1CD создавалась как исследовательская программа формата 1CD, без всякого плана, тех. задания и вообще без всякого представления, что в итоге получится. Дополнительные инструменты в Tool_1CD создавались хаотично, по мере возникновения потребности, поэтому не стоит искать в этом наборе инструментов стройность, законченность и т.д.

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

Все дополнительные инструменты располагаются на странице «Дополнительно»:

Страница Дополнительно

Приведу краткое описание всех элементов управления, расположенных на этой странице.

Поле ввода «Директория импорта/экспорта таблиц»

В этом поле выбирается каталог для записи и чтения таблиц. Этот каталог используют инструменты «Экспорт текущей таблицы», «Импорт текущей таблицы», «Экспорт таблиц данных», «Импорт таблиц данных», «Импорт и создание таблиц».

Кнопка «Экспорт текущей таблицы»

По этой кнопке создается каталог с именем текущей таблицы в каталоге импорта/экспорта таблиц. В созданный каталог записываются все 4 файла текущей таблицы (DESCR, DATA, INDEX и BLOB), а также вспомогательный файл root.

Кнопка «Импорт текущей таблицы»

По этой кнопке в директории импорта/экспорта таблиц ищется каталог с именем текущей таблицы. Если каталог найден, у текущей таблицы перезаписываются файлы DATA, INDEX и BLOB файлами из найденного каталога. Файл DESCR при этом остается неизменным! Это позволяет, например, переносить данные из другой базы с такой же конфигурацией, но с другими именами таблиц (другой нумерацией объектов конфигурации). Для этого нужно будет только переименовать каталог с именем выгруженной таблицы, и присвоить ему имя таблицы, в которую мы импортировать данные. Если при этом порядок полей, количество и тип (но не имена!) будут не совпадать, таблица получится битая!

Кнопка «Экспорт таблиц данных»

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

Кнопка «Импорт таблиц данных»

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

Кнопка «Импорт и создание таблиц»

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

Если такая таблица существует, то в существующей таблице перезаписываются файлы DATA, INDEX и BLOB файлами из каталога, файл DESCR не изменяется!

Если же таблица с таким именем не существует, то создается новая таблица из файлов в каталоге.

Кнопка «Удаление текущей таблицы»

Удаляет текущую таблицу.

Кнопка «Удалить лишние таблицы»

Производит поиск и удаление таблиц, имена которых оканчиваются на «NG», «OG», а также таблицу «DBCHANGES». Все эти таблицы являются временными при реструктуризации базы, и могут остаться в базе, только если произошел сбой при реструктуризации. Внимание! Удалять таблицы, оканчивающиеся на «NG» или «OG» имеет смысл, если существует таблица с таким же именем, но без суффикса «NG» или «OG».

Кнопка «Найти дубли таблиц»

Производит поиск таблиц с одинаковыми именами. Найденные имена выводятся в окно сообщений.

Поле ввода и кнопка «Создание и импорт таблицы»

В поле ввода выбирается каталог с экспортированной из другой базы таблицей. По нажатию кнопки читается имя таблицы из файла DESCR в выбранном каталоге.

Если такая таблица уже существует в базе, то в существующей таблице перезаписываются файлы DATA, INDEX и BLOB файлами из каталога. Файл DESCR существующей таблицы не изменяется!

Если таблица с таким именем не существует, то создается новая таблица из файлов в каталоге.

Кнопка «Проверка всех индексов»

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

Кнопка «Найти потерянные объекты»

Объект — это внутренний файл, описанный в разделе «Структура базы данных 1CD». При нажатии кнопки «Найти потерянные объекты» происходит просмотр всех страниц файла базы данных и проверка начала каждой страницы на сигнатуру «1CDBOBV8», являющейся признаком начала заголовочной страницы файла. Если найдена сигнатура, делается проверка, принадлежит ли файл одной из таблиц и не является ли этот файл корневым. Если нет, то в окно сообщений выводится сообщение о найденном объекте с указанием адреса. Стоит отметить, что даже в исправных базах часто встречаются такие потерянные объекты, особенно после реструктуризации. Эти файлы были штатно удалены, и сам по себе факт наличия потерянного файла ни о чем не говорит. Но иногда, в редких случаях, эта информация может помочь найти действительно нужную утерянную информацию. Например, если испорчен файл описания таблицы, но сохранились другие файлы таблицы. См. также «Поиск и восстановление потерянных таблиц» и «Найти и сохранить потерянные объекты».

Кнопка «Тест формата потока»

Одна из самых частых ошибок, приводящих к невозможности запуска конфигуратора и/или предприятия — это ошибка формата потока. В терминологии 1С «поток» — это тектсовое представление двоичных объектов, получаемое в процессе сериализации. Это представление необходимо, чтобы сохранять программные объекты в базе, в файлах, для передачи по сети и т.д. Почти вся конфигурация, хранимая в базе или выгруженная в файл — это набор сериализованных объектов конфигурации. Хранилище значения хранит объекты в сериализованном виде. Методы 1С ЗначениеВСтрокуВнутр(), СохранитьЗначениеВФайл() и т.д. сериализуют объект. Все настройки пользователей хранятся как сериализованные данные. Сериализованные потоки используются 1С повсеместно. Если в любом из перечисленных мной мест, или в еще куче не перечисленных текстовое представление портится, возникает «ошибка формата потока». Из-за того, что сериализованные потоки 1С использует буквально везде, такая ошибка возникает очень часто, и при этом 1С даже приблизительно не намекает в каком же месте возникла эта ошибка. Сообщение «Ошибка формата потока» претендует на звание самого бесполезного сообщения об ошибке в мире!

Инструмент «Тест формата потока» пытается проверить формат потока в записях основных системных таблицах: CONFIG, CONFIGSAVE, FILES, PARAMS и DBSCHEMA. Ошибки формата потока именно в этих таблицах могут приводить к невозможности запуска конфигуратора и предприятия. Однако следует понимать, что такая проверка не совсем корректна. Для полностью корректной проверки необходимо разобрать и описать структуру конфигурации и других записей системных таблиц, но это очень кропотливая работа и на данный момент в открытом доступе такого описания нет.

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

Кнопка «Создать пустой объект в базе»

Создает новый файл (объект) в базе. Длина нового файла равна 0. Файл никому не принадлежит. Иногда это бывает нужно при ручном восстановлении структуры БД. Этот инструмент можно считать устаревшим.

Кнопка «Создать объект из файла»

Создает новый файл (объект) в базе. Содержимое файла копируется из указанного внешнего файла. Файл никому не принадлежит. Иногда это бывает нужно при ручном восстановлении структуры БД. Этот инструмент можно считать устаревшим.

Кнопка «Проверка состава таблиц»

Проверяется существование в базе каждой таблицы данных (но не системных таблиц!), описанной в записи DBNames таблицы PARAMS. Записи про системные таблицы (с идентификатором 00000000-0000-0000-0000-000000000000) пропускаются, так как часто такие таблицы в базе отсутствуют, но это не является ошибкой. Подробнее про DBNames смотри выше в разделе «Структура информационной базы 1С».

Кнопка «Поиск и восстановление потерянных таблиц»

Производится поиск всех таблиц, которые есть в базе, но которые не содержатся в корневом файле. Работает также как и инструмент «Найти потерянные объекты», но при нахождении потерянного файла (объекта) дополнительно проверяется, не является найденный файл файлом описания таблицы (DESCR). Если да, то таблица добавляется в корневой файл.

Найденные таблицы могут оказаться удаленными таблицами после реструктуризации. Однако, если таблицы пропали в результате ошибки в корневом файле, инструмент может восстановить реальные таблицы.

После описанной в разделе «Стандартные средства восстановления» искусственной порчи базы, до применения chdbfl.exe, данным инструментом можно было бы восстановить таблицы обратно.

Кнопка «Найти и сохранить потерянные объекты»

Работает аналогично инструменту «Найти потерянные объекты«, но, дополнительно, каждый найденный потерянный файл сохраняетс в файл на диске. Файлы сохраняются в каталог «LostObjects», который создается в папке, в которой лежит файл базы.

Кнопка «Тест формата потока внешнего файла»

Позволяет произвести проверку на корректность формата потока внешнего текстового файла, например, сохраненного из этой или другой базы. Как пример — распакованное содержимое файла выгрузки базы 1Cv8.dt является одним большим текстовым файлом-потоком. Корректность этого файла можно проверить данным инструментом.

Ограничения проверки такие же, как и в инструменте «Тест формата потока».

Поле ввода «Файл соответствия номеров» и кнопка «Замена TREF»

Иногда в процессе восстановления возникает необходимость переноса таблиц из одной базы в другую базу с такой же конфигурацией, но с несовпадающей нумерацией в DBNames. Например, разрушена таблица в центральной базе, но нужная таблица есть в периферийной базе. Кроме того, что в таких базах не совпадают имена таблиц и полей, которую можно решить правкой файла описания таблицы, есть еще проблема несовпадения типов ссылок, которые хранятся в полях с окончанием «TREF». Подробности описаны в разделе «Структура информационной базы 1С«. Данный инструмент позволяет произвести замену всех значений во всех таблицах базы в полях с окончанием TREF. Список замен должен содержаться в файле, выбираемом в поле ввода. Файл представляет собой текстовый файл. В каждой строке файла содержатся два числа, разделенных табуляцией. Второе число — заменяемое. Все поля, содержащие такое значение, заменяются на первое число строки.

Все замены производятся без изменения индексов в базе!

 

Заключение

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

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

Статья появилась в результате подготовки и проведения мастер-класса на Infostart Event Evolution 2013. Хочу поблагодарить всех организаторов конференции и лично Ирину Пятакову, без них этой статьи точно не было бы.


99 Comments

  1. m.bolsun

    Серьезная работа.

    Добавил в закладки.

    Reply
  2. m.bolsun

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

    Reply
  3. awa

    (2) Чисто теоретически можно, но дело в том, что об этом не будет знать конфигуратор. Конфигуратор уверен, что он запущен один, и не будет проверять, что кто-то что-то поменял в этот момент в конфигурации в базе. Для замены текстов модулей и имен реквизитов гораздо лучше подходит снегопат, имхо.

    Reply
  4. m.bolsun

    (3) ок, буду думать, спасибо.

    Reply
  5. glek

    Капитальная работа. Если б можно было — поставил бы несколько плюсов. Спасибо

    Reply
  6. andrewks
    Еще одна неприятная особенность утилиты «chdbfl.exe» заключается в том, что в результате ее работы база может получиться корректной с точки зрения движка баз данных, но некорректной с точки зрения программ конфигуратора и предприятия. Например, было несколько случаев, как под копирку, когда в базе портился единственный индекс таблицы CONFIG, и «chdbfl.exe», вместо того, чтобы создать индекс заново, просто удаляла индекс в таблице совсем. После такого «исправления» не работали ни конфигуратор, ни предприятие.

    думаю, тут надо отметить, что такое поведение только при отжатой галке «исправлять ошибки», ибо при нажатой происходит полное перестроение индексов

    Reply
  7. awa

    (6) При отжатой галке chdbfl.exe вообще не изменяет базу, а только проверяет ее.

    chdbfl.exe перестраивает индексы, если считает, что с ними все хорошо. Но если chdbfl.exe решит, что что-то с индексами не так, то просто убивает индекс. Я не знаю, как испортить базу именно так, чтобы индекс был убит, но то, что было несколько таких случаев — факт.

    Reply
  8. andrewks

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

    но то, что в алгоритмах чтения при отжатой галке утилита к индексам обращается, а при нажатой игнорирует — это факт, проверенный мной не единожды.

    например, у меня были случаи с «протухшими» индексами, в итоге база не открывалась ни в предприятии, ни в конфигураторе (происходило банальное зависание).

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

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

    1С, естественно, тупо не видит таких записей, т.к. их нет в индексах.

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

    я думаю, это напрямую связано с логикой работы алгоритма с галкой:

    копируем всё, что можно считать, при этом игнорируем индексы, далее строим индексы ко всем перенесённым таблицам (это можно также увидеть и по номерам файлов индексов в результирующей базе)

    Reply
  9. andrewks
    Из-за того, что сериализованные потоки 1С использует буквально везде, такая ошибка возникает очень часто, и при этом 1С даже приблизительно не намекает в каком же месте возникла эта ошибка. Сообщение «Ошибка формата потока» претендует на звание самого бесполезного сообщения об ошибке в мире!

    неистово плюсую!

    Reply
  10. Evil Beaver

    Неистовый плюс! Спасибо! Предыдущую Вашу статью про формат 1CD понять так и не смог )

    Reply
  11. Антон Ширяев

    Спасибо за интересные и познавательные статьи как эту, так и предыдущую по формату файлов 1CD.

    Данный инструмент делает некоторые проверки формата (например, соответствие открывающих «{» и закрывающих «}» скобок), но не все. В некоторых случаях возможны ложные сообщения об ошибках.

    Можно более подробно какие проверки при этом делаются? Проверяется только сам факт парности фигурных скобок {} или учитывается, что в принципе непарная фигурная скобка может быть внутри кавычек? Проверяется ли парность кавычек?

    Если есть время/желание опишите кратко этот алгоритм пожалуйста.

    Reply
  12. awa

    (11) Нет, конечно же не только парность скобок. Делается полный парсинг потока в дерево с попыткой определения типа каждого элемента. Допустимые типы — строка, числo, GUID, ссылка, двоичные данные. Если не удается определить тип элемента — выдается ошибка. Скобка внутри строки обрабатываются правильно.

    Проверка идет формально. Нет знания, сколько и каких элементов где должно быть. Например, 1С ожидает в каком-то месте потока последовательность {<число>,<GUID>,<число>}, а получает {2,24341234,74}, то для 1С это будет ошибка формата потока, а у меня ошибки не будет. Но если там будет {2,2й341234,74} — то ошибка будет и в 1С, и у меня.

    Reply
  13. TrinitronOTV

    спасибо автору за подробно изложенную структуру файловой базы данных, весьма полезная информация для меня

    Reply
  14. andrewks

    (12) я тоже такое делал.

    составил вот такой список типов:

    // типы значений в древововидных списках 1С:

    // пусто

    // число

    // дата ?

    // строка

    // GUID

    // #base64:

    // raw base64

    // вложенный список {}

    кстати, вопрос, который остался у меня алгоритмически неразрешённым: каким образом 1Сина отличает дату от числа? не смог уловить критерия

    (если в опред.месте 1сине вместо даты поставить число-мусор (невалидную дату), то тоже вылезет ошибка формата потока)

    Reply
  15. awa

    (14) 1С всегда точно знает, какой объект она сериализует и десериализует, и поэтому 1С в каждом элементе ожидает конкретный, известный ей тип. Если она ждет дату, то и будет читать очередной элемент как дату, а не как число. Мы же не знаем, какие типы где должны быть. Поэтому мы и не можем отличить число от даты, и поэтому в моем списке типа дата нет.

    Я уже как-то писал об этом, в своем декомпиляторе я разобрался до конца с форматом файлов компилированного кода image, так вот там я точно знаю, когда нужно ждать дату, а когда число, поэтому там я их отличаю.

    Reply
  16. LexSeIch

    Мир этому дому!

    Тема затронутая в статье интересная. Конечно, до поры до времени можно относится к файловой БД 1С, как к «черному ящику». Но рано или поздно наступает момент, когда хочется знать о ее структуре больше, например при увеличении размера до критического… Но и тема восстановления, то же важна. Особенно в статье радует обилие ссылок — автор хорошо поработал и облегчил жизнь многим. Плюс и спасибо!

    Reply
  17. Evil Beaver

    (15)

    в своем декомпиляторе я разобрался до конца с форматом файлов компилированного кода image

    awa, не было мыслей сделать оптимизатор байткода? Как считаете есть вообще прикладной смысл вообще думать в этом направлении?

    Reply
  18. awa

    (17) Именно оптимизатор — нет, имхо, смысла нет. Неоднократно обсуждалось в разных ветках здесь на инфостарте, особого выигрыша от этого не получишь. Прирост в скорости от оптимизации будет от долей процента до максимум 2-3 процентов (цифры с потолка, подтвердить я их не могу, но я в них почти уверен). Основные задержки идут при обращении к БД (запросы, получение свойств через точку и т.д.). Вот тут поле для оптимизации!

    Резюмируя мое имхо: плохой код невозможно ускорить (оптимизировать), хороший код ускорять не нужно!

    Reply
  19. Evil Beaver
    плохой код невозможно ускорить (оптимизировать)

    Ну промышленные компиляторы же оптимизируют. Есть ряд канонических примеров, наподобие выноса выражения из цикла и т.п. То есть «плохой» код, наверное, можно ускорить.

    Помнится, я в армии служил на большой советской ЭВМ, так даже там уже был оптимизирующий компилятор АЛГОЛа (или ФОРТРАНа, не помню) и к нему книжка о том, как он замечательно все ускоряет.

    Reply
  20. andrewks

    (19) Evil Beaver, можно оптимизировать машинный код при компиляции. но не забывайте, что в случае 1С машинный код находится не в .epf и не в .cf, а в бинарных файлах .dll 1С-а

    Reply
  21. awa

    (19) Начал писать развернутый ответ про регистры, стеки, систему команд процессоров и т.д., понял, что увлекся и стер)) Вкратце суть — оптимизировать в байт-коде практически нечего, нет пространства для маневра, в отличие от компиляторов в машинный код.

    Reply
  22. Evil Beaver

    (20),(21) Спасибо. Мне почему-то казалось что можно… Там же и коды операций и адреса все присутствует… А нет у вас матчасти почитать? Мне любопытно.

    Reply
  23. awa

    (22) Нет, в открытом доступе таких сведений нет, насколько я знаю. Все, кому интересно, действовали одинаково. Ставили пароль на модуль в обработке/конфигурации, распаковывали с помощью V8Unpack, и изучали файлы image.

    Reply
  24. BobNN

    Огромное спасибо за этот труд!

    Поднял с помощью этого инструмента базу, которая не входила даже в конфигуратор. Более того, до меня её уже прогнали chkdbfl. Архивная копия была полугодовалая, в общем всё плохо.

    НО! Победил)))

    (правда пришлось пожертвовать одной таблицей)

    Кстати, есть несколько моментов по работе программы. Если интересно, напишу (когда успокоюсь после ТАКОГО восстановления)

    Reply
  25. Evil Beaver

    (23) не я не по конкретную матчасть 1С. Я про то, почему байт-код нельзя оптимизировать

    Reply
  26. awa

    (24) Я рад, значит не зря писал все это)) Глюков в программе еще очень много, это я знаю, но отзыв все равно будет полезен!

    (25) Я не говорил, что его нельзя оптимизировать, я говорил, что это не даст особого выигрыша. У нас получается слишком теоретический разговор, потому что я говорю про конкретный набор команд виртуальной машины 1С и особенности его применения (когда большую часть времени исполняется не сам байт-код, а функции, вызванные им), а Вы говорите про низкоуровневую оптимизацию, которая имеет смысл только на тяжелых вычислительных задачах, практически не встречающихся в 1С.

    Reply
  27. Evil Beaver

    (26) теперь понятно. Насчет малого выигрыша я согласен. Я подумал, что это теоретически тоже невозможно. Вот и удивился. Еще раз спасибо за статью!

    Reply
  28. gradus

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

    Reply
  29. alexpvs

    Большое спасибо, очень полезная статья!

    Reply
  30. karakozov

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

    Reply
  31. Al-X

    Спасибо автору ! У меня есть база УТ 11, которая время от времени падает. Лечил chkdbfl и даже не очень волновался.. ну подумаешь пропали пару документов.. 🙁

    Теперь буду осторожен, «лечилку» chkdbfl буду использовать крайне НЕ ОХОТНО !! Буду разбираться в структуре 1CD, авось пойму, причину падения базы.

    Reply
  32. sasha_r

    Огромная благодарность за проделанную работу.

    Статья заняла прочное место в избранном!

    PS: Там есть небольшие опечатки, но это не фатально.

    Reply
  33. Гость

    Очень полезная статья. Спасибо. А не подскажете где можно найти описание таблицы config (для файловой базы) — интересует что должно содержаться в строках VERSION, VERSIONS, ROOT из этой таблицы. Буду рад любой ссылке по теме. С помощью Tool_1c вычислили, что проблема нашей рухнувшей базы именно в этих строках. Цель — спасти cf-ник (сильно доработан). Есть старый архив базы, но после этого архива уже меняли/добавляли пару справочников, документов. Может он, хотя бы, частично поможет.

    Reply
  34. awa

    (33) Елена, Вы совершенно правы, что записи root, version и versions подойдут от старого cf. Вы можете попытаться восстановить конфигурацию с помощью v8Unpack (http://infostart.ru/public/15695/) — Вам надо распаковать старую конфигурацию, и взять оттуда файлы root, version и versions.

    Битую конфигурацию Вы можете попробовать распаковать в файлы либо сохранив конфигурацию через Tool_1CD и затем распаковать с помощью v8Unpack, либо сохранить таблицу CONFIG в XML c флажком «При экспорте в XML сохранять BLOB в отдельные файлы», тогда в директории CONFIG.xml.blob Вы получите такие же распакованные файлы, как и после v8Unpack.

    Замените нужные файлы (root, version и versions) из старой конфигурации и соберите конфигурацию снова.

    Reply
  35. AB_74

    (34) Строки version и root вставили из старой конфигурации (с помощью Tool_1CD альфа). После этого:

    1) при отсутствии строки version в таблице config база запускается в режиме «предприятие», а в режиме «конфигуратор» — конфигуратор открывается, но при открытии конфигурации выдает»ошибка формата потока»

    2) при вставке строки versions из старой конфигурации «ошибка формата потока» появляется уже на этапе запуска конфигуратора

    Скорее всего содержимое versions из старой конфигурации не подходит, т.к. битая конфигурация с того времени уже была переработана и добавлены новые объекты (т.к. конфигурации различны).

    Есть предположение что в binarydata в сроке versions содержится перечисление filename и еще чего-то. Поэтому и интересует — можно ли вручную составить содержимое для строки versions?

    Reply
  36. mau89

    Здравствуйте подскажите пожалуйста, вот такой вопрос. У меня имеется битая база, при ПиТ выдает ошибку «Ошибка СУБД:

    Ошибка SQL таблица не найдена _Document193″ и все выключается. Пробую chkdbfl, говорит ошибок нет. Через программу Tool_1CD в типовой конфигурации нашел эту таблицу, сохранил ее в формате xml, а вот загрузить в битую базу не получается. Делаю вот так, в Директория импорта/экспорта таблиц выбираю папку с данным документом, нажимаю импорт текущей таблицы, импорт таблиц данных и никаких действий не происходит. Подскажите что я не так делаю? Конфигурация Зарплата и кадры бюджетного учреждения, 1.0.54.3

    Заранее благодарен

    Reply
  37. awa

    (36) Выгрузка в XML не предназначена для обратной загрузки в базу. Для переноса таблиц из базы в другую базу надо пользоваться кнопками «Экспорт текущей таблицы», «Импорт текущей таблицы» и «Создание и импорт таблицы».

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

    Reply
  38. sergb1979

    Отличное описание.

    В 1с всегда не хвататет прозрачности

    Reply
  39. zels

    Встретилась база (файловая) со странной ошибкой — при нажатии кнопки «перейти» в справочнике ОС появляется много дублей строк. Тестирование не помогает, chkdbfl тоже. Выгрузка-загрузка в файловую и SQL — тоже не сработали.

    Запустил Tools_1CD, на закладке «Дополнительно» понажимал все кнопки «проверить». Увы, дубли не исчезли (только были сообщения что не определилась кодировка). Я предполагаю, что меню «перейти» формируется самой платформой, но где, из каких таблиц она берет информацию — непонятно.

    Reply
  40. awa

    (39) Надо просто оторвать руки редактировавшему форму. На командной панели в конфигураторе сначала сделали «Заполнить автоматически» (в контекстном меню), затем еще поставили галку «Автозаполнение». Затем лишние кнопки были удалены, но не все. Это выдает 2 кнопки «Справка». В результате связанные регистры задвоились.

    Надо снять галку «Автозаполнение» у командной панели (а затем, при необходимости, снова поставить).

    Reply
  41. zels

    (40) Спасибо, сработало!

    Reply
  42. mirFis

    Уважаемый awa, подскажите, пожалуйста, почему в 7.7 вылетает такая ошибка: «Общая файловая ошибка при доступе к 1Сv7.MD» (в режиме запуска предприятия), и «Общая файловая ошибка при доступе к С:TEMP~md4357.tmp» (в режиме запуска конфингуратор).

    Reply
  43. awa

    (42) Сорри, но я с семеркой не имел дела уже лет семь, может кто-то еще сможет ответить на этот вопрос.

    Reply
  44. zels

    (42), посмотрите, есть ли такая папка и можете ли Вы писать/читать файлы в этой папке.

    Антивирус может мешать, попробуйте отключить.

    Reply
  45. sasha_r

    (42) mirFis, с правами доступа на NTFS всё нормально?

    про антивирус уже посоветовали — желательно эту версию тоже проверить.

    Reply
  46. mirFis

    (44) Если речь идет о папке БД — то да, она есть, писать/читать файлы этой папки можно.

    Пробовал отключать Антивирус, не помогло.

    (45) А какие проблемы могут возникать с правами доступа на NTFS?

    Разъясните, пожалуйста.

    Reply
  47. sasha_r

    (46) mirFis, если права на NTFS даны не всем пользователям на полный доступ, то нормально с этой папкой/файлами работать из 1С не получится.

    Надо посмотреть под кем запускается 1С и есть ли права у этого пользователя на эту папку.

    В качестве альтернативы можен попробовать запустить 1С «от имени администратора» (включить соотв. галку в ярлыке запуска) — это это если MS Vista, 7 или выше.

    Я бы лично начал с разбора прав на папки на диске.

    Reply
  48. mirFis

    Думаю, лучше один раз увидеть, чем сто раз не понять.

    Вообщем, выложу файл для ясности.

    Reply
  49. igorek_zh

    Добрый день! Не могли бы оказать помощь в восстановлении базы 1с:КА8. Есть База убитая и ее копия месячной давности. Конфигурации идентичны(типовые). Проблема при запуске в режиме предприятия — файл базы данных поврежден, если попробовать прогнать chkdbfl — то говорит, что есть ошибка в CONFIG и якобы исправляет ее, но после этого не стартует ни в каком режиме, вываливается с ошибкой — ошибка формата потока. Пробовал через HEX редактор заменить CONFIG — вроде все срастается, только при запуске больше не видит конфигурацию, открывается пустая, как для новой разработки. При этом объем базы не изменяется, данные в ней точно есть.

    Reply
  50. oleg212

    Отличнейшая статья! Большое спасибо автору!

    Плюсую!

    Reply
  51. LADNN

    отличная статья.

    спсбо автору.

    +

    Reply
  52. JSverhnovaya

    Подскажите пожалуйста, по какой причине при попытке использования дополнительных функций программы Tool1cd (например, создание и импорт таблицы) на поврежденной базе может вылетать ошибка: «access violation at adress…». Скриншот ошибки в прикрепленном файле.

    Reply
  53. zels

    Интересно, в какой таблице хранится конфигурация поставщика?

    Reply
  54. awa

    (54) Конфигурации поставщика хранятся в файлах вида <GUID>.<GUID> (например, «d3392495-1b10-4a33-b8d4-645a664e0270.fe2937c8-87af-4717-97fd-644ace26b685») в таблицах CONFIG и CONFIGSAVE.

    Reply
  55. awa

    +(55)в предыдущем сообщении съелись угловые скобки. Имелось ввиду «в файлах вида GUID.GUID»

    Reply
  56. Bukaska

    Интересная статья, добавила в закладки)))

    Reply
  57. zels

    Скачал Tools 0.3.1 (461)

    Открываю типовую бухгалтерию 2.0, жму «найти конфигурации поставщика» и вижу сообщение:

    «конфигурации поставщика не найдены»

    Reply
  58. awa

    (58) Если режим изменения не включен, то основная конфигурация и есть конфигурация поставщика. 1С сохраняет в файлах вида GUID.GUID конфигурацию поставщика только когда основная конфигурация отличается от конфигурации поставщика, т.е. когда включен режим изменений.

    Reply
  59. newborn

    Очень интересная программа Tool_1CD. Но крайне нужна функция удаления всех таблиц по маске. Это нужно не для восстановления базы а для быстрой очистки её. Например для удаления всех документов. Да, при этом пострадает целостность. Но после можно запустить штатное восстановление конфигурации для удаления битых ссылок. Идея такая, как мы раньше использовали на v7 — удалить все файлы, которые начинаются на D*.dbf — и база очищена от документов. Я понимаю, что это некорректно и всё такое прочее. Но иногда очень надо.

    Reply
  60. vis_tmp

    Огромное спасибо за информацию и за утилиту!

    Reply
  61. zels

    Интересно, что будет, если количество свободных блоков превысит 4 гб и они не влезут в таблицу…

    Система сама, «на лету» проведет сжатие базы?

    Reply
  62. alexpvs

    Огромное спасибо за столь полезную утилиту!

    Reply
  63. fixin

    Спасибо. Появилась надежда теперь на восстановление файловых баз, проблема, которую 1С не хочет признавать. «Запись NULL в поле, не допускающее NULL»

    http://infostart.ru/public/66060/

    Reply
  64. Chaplain

    Друзья, добрый день! А ни у кого случайно нет контактов автора. Срочно хотелось бы с ним связаться. Если есть такая возможность, то буду благодарен!

    Reply
  65. Bukaska

    (66) Chaplain, Только если через форум.. через сообщения..

    Reply
  66. mesterio

    День добрый.

    Проблема такая 1с 8.2 ЗУП запускается и даже работает. Конфигуратор тоже запускается и выгружает конфигурацию. Но при выгрузке информационной базы говорит что БД повреждена. chkdbfl так же заканчивает сообщением о повреждении БД без каких либо подробностей.

    Reply
  67. francas

    День добрый!

    При открытии Основной конфигурации 1С 8.3 (бухгалтерия 2.0) пишет ошибку «Нарушена структура целостности конфигурации».

    Тестирование и исправление базы и chkdbfl — не помогает, ошибок не находит. Как восстановить базу??

    Reply
  68. zels

    Какой релиз? Сбой после обновления релиза?

    Reply
  69. Вальская Людмила

    Все же так просто — для просмотра структуры пользуйтесь методом глобального контекста ПолучитьСтруктуруХраненияБазыДанных() (http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=550839) — почему об этом не написано на всех заборах???

    Reply
  70. Armando

    (71) Вальская Людмила, чукча не читатель?

    Reply
  71. zels

    Но, черт возьми, как? (Ватсон)

    (71) Вальская Людмила, КАК на основании содержания статьи Вы пришли к своему совету? Почему не к совету «отказаться от Вискас»?

    Reply
  72. zels

    Смотрю на битую базовую бухгалтерию и сравниваю с точно таким же релизом рабочей базы. С удивлением обнаруживаю, что номера практически всех таблиц таблиц и полей — разные. Странно, что базовая кофигурация обновляется так по-разному.

    Есть ли способ заменить config в битой базе с заменой номеров таблиц и полей?

    Что означает окно «External exeption EEFFACE» ? Оно появляется при позиционировании на таблицу регистра накопления. Я удалил эту таблицу, потом сделал «Поиск и восстановление потерянных таблиц» — все равно появляется.

    Reply
  73. Gtrby2008

    Есть срочная необходимость в восстановлении информационной базы 1с 8.2.

    При запуске 1с 8.2.19.130 выдается сообщение

    Файл базы данных поврежден 1Cv8.1CD

    При запуске утилиты chdbfl.exe

    Поврежден заголовок файла базы данных

    Повреждено содержимое внутреннего файла <Описание базы данных>

    ВОЗМОЖНО ЛИ ВОССТАНОВИТЬ БАЗУ ДАННЫХ?

    Reply
  74. Cooler

    (75) Gtrby2008,

    ВОЗМОЖНО ЛИ ВОССТАНОВИТЬ БАЗУ ДАННЫХ?

    Хороший вопрос — для тестирования телепатов.

    А для спеца надо видеть базу — бывало, просили тут восстановить, а 1CD был объемом в несколько десятков мегабайт — то есть ошметки от базы.

    Поэтому совет: заархивируйте свою базу и выложите на Яндекс-диск или в файлообменник, а ссылку опубликуйте или вышлите тому, кто вызовет у вас доверие.

    Ну, или удаленный доступ. Других способов я не вижу.

    Reply
  75. zels

    Тоже жду ссылку.

    Reply
  76. Cooler

    (77) zels, в другой ветке Gtrby2008 оставил свою почту, можете сами связаться с ним, если хотите.

    P.S. Интересно, много написало?

    Reply
  77. IGGS

    Бухгалтерия предприятия ред. 3.0

    Файл базы данных поврежден 1Cv8.1CD

    При запуске утилиты chdbfl.exe

    Поврежден заголовок файла базы данных

    Повреждено содержимое внутреннего файла <Описание базы данных>

    ВОЗМОЖНО ЛИ ВОССТАНОВИТЬ БАЗУ ДАННЫХ?

    Или вытащить все данные и залить в чистую конфигурацию?

    Если да, то сколько это будет стоить?

    Если есть спецы, вышлю базу!

    Reply
  78. Cooler

    (79) IGGS,

    ВОЗМОЖНО ЛИ ВОССТАНОВИТЬ БАЗУ ДАННЫХ?

    Вы скопировали вопрос из (75)? А почему не прочитали ответы на него? С вашего позволения, я не буду их повторять, времени жалко.

    Reply
  79. zels

    (79) IGGS, киньте ссылку на базу.

    Reply
  80. ooomalina

    Добрый день.

    Можно ли восстановить базу.

    1С подключили через локалку, после 2 дней работы слетела с ошибкой dbeng8

    После использовал утилиту chdbfl.exe

    После чего не встали заказы. Что делать, не знаю.

    Прошу помочь.

    Reply
  81. ooomalina

    Напишите свои условия по расценке.

    Reply
  82. Cooler

    (83) ooomalina,

    Напишите свои условия по расценке.

    От нуля до статыщ.

    Точнее — к телепатам.

    Reply
  83. ooomalina

    Ну сколько по практике берут за подобную процедуру?

    2000, 3000, 5000 руб?

    Reply
  84. Cooler

    (85) ooomalina,

    сколько по практике берут за подобную процедуру?

    А сколько на практике берут за ремонт машины?

    Потерпите, потерпите: скоро должны подтянуться телепаты, они напишут — какие сообщения вам выдала chdbfl и тогда можно будет назвать ориентировочные цифры.

    А еще телепаты сообщат — сохранился ли у вас оригинал базы до «лечения», если нет — наверняка стоимость «ремонта» будет нулевой.

    Reply
  85. zels

    (85) ooomalina, киньте ссылку на базу. Сначала надо провести диагностику, хотя бы быструю и оценить масштабы.

    Reply
  86. Светлый ум

    Отсутствует таблица dbschema, какими средствами её можно скомпилировать?

    Reply
  87. Светлый ум
  88. BAE1234567

    С ума сойти!! Очень интересно!

    Reply
  89. zels

    Вопрос к awa: Валерий, планируете ли Вы модернизацию (или новую версию) Tool_1CD для работы с 1CD-файлами формата 8.3.8 ?

    Reply
  90. awa

    (91) Версия без редактирования поддерживает формат 8.3.8 уже давно. Версия с редактированием формат 8.3.8 не поддерживает. На данный момент никаких доработок не планируется и из-за нехватки времени, и из-за того, что инфостарт убрал Tool_1CD с сайта по требованию 1С.

    Ссылки см. тут http://infostart.ru/community/groups/318/forum/156819/

    Reply
  91. zels

    (92) спасибо, скачал.

    Т.е 1С вместо «спасибо за спасенные пользовательские базы» наезжает… Хороните ваши базы, дорогие клиенты!

    Я правильно понимаю, что в новом формате и размеры блоков выросли и количество блоков в файле тоже?

    Теперь у меня есть 2 версии Tool_1C 0.3: 0.3.0 alpha от 2015г и 0.3.1 alpha от 2014г и я не пойму, какая новее…

    Reply
  92. Acki

    awa, писал Вам на почту. Мы удалили базу мимо корзины, восстановили с жесткого диска программой, но база не ожила. Местные специалисты по 1С не помогли. Что нибудь можно сделать или такое не восстанавливается и забивать все за два года руками?

    Reply
  93. FKLDOZ

    Спасибо автору за статью! Супер!

    Сделала закладочку.

    Не попалась мне, когда надо было восстанавливать БД, взяла из копии.

    А интересно было бы покопаться ради учебы.

    Reply
  94. sss999

    Здравствуйте. Хотелось узнать как располагаются данные таблицы документа, если смотреть через hex редактор. Одной таблицы нет, но хочется поискать ее данные. Искал по названию таблицы, нашел только табличные части.

    Reply
  95. Stirlitz

    При всем моем глубоком уважении к автору, неужели нельзя было сделать простой поиск значения по таблице (закладка «Физическое представление»)?

    Reply
  96. zels

    (98) А попробуйте! Увидите, что «простой поиск» совсем не прост.

    Reply
  97. Stirlitz

    (99)

    Вы имели в виду саму реализацию поиска или я чего-то не увидел?

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

    Reply
  98. zels

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

    Кстати, само 4015 похоже на 2015+2000 (сдвиг для SQL базы). Иногда при выгрузках-загрузках получаются ошибки подобного типа. Если база SQL, можно использовать прямые запросы к ней, без 1С.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *