Обработка для анализа ошибок в структуре DBShema, восстановление структуры объектов, перенос данных из выгруженных в XML таблиц базы, при помощи «Tool 1CD».
Ситуация
Маленькая файловая база Бух3, учёт ведется 4 года, во время очередного обновления вылетает конфигуратор, при повторной попытке обновления имеем сообщение о невозможности применить изменения конфигурации.
Стандартный алгоритм действий:
- Долго себя ругаем за лень при создании архива перед обновлением;
- Откатываем конфигурацию на версию БД. При попытке запустить базу – ошибка, что таблица такая-то не найдена и вылет;
- Конфигуратор – тестирование и исправление, опять ошибка, что таблица такая-то отсутствует и невозможность ремонта;
- Попытка залить предыдущую типовую конфигурацию – опять критическая ошибка SDBL;
- Последняя попытка – выгрузка базы в DT, проходит частично и вылетает. При загрузке DT – получаем базу с 90% пустых таблиц и сохранившейся ошибкой при тестировании и исправлении.
- С удивлением узнаем, что у админа нет архивных копий от слова совсем;
- Осознание того, что проблема серьезная и требуется помощь. Отправка запроса в 1С и замечательный ответ о том, что ваша база разрушена, поэтому восстановите базу из архивной копии и будет вам хорошо.
- Гуглим, находим “Tool 1CD”, с горечью осознаём, что с версией 8.3.8 он работает только на чтение. Вывод – что-то чинить можно в режиме SQL.
- Загружаем базу из ранее выгруженного DT. Получаем те же проблемы, но на этот раз можно использовать Profiler и, например, создать недостающие таблицы, поля.
- Некоторое время закрываем проблемы по отсутствующим полям на SQL, пока не получаем вот такое сообщение
При условии работающей базы, мы вполне можем узнать что это за регистр, но работающей базы у нас нет, от слова совсем. - Опять гуглим на предмет: «А что такое схема базы данных», и вот тут информация крайне скудная. Официальная трактовка от 1С:
- Открываем эту табличку в SQL, это бинарные данные. Выгружаем их в файлик, открываем его Notepad++ и видим набор массивов с описанием полей базы:
Попытка найти информацию о том, что же это всё такое – результат нулевой. Ок, значит разбираться придётся самому. Перечитывание нескольких статей на инфостарте даёт понимание необходимости просмотра также данных сопоставление объектов конфигурации в файлике DBNames и самой конфигурации 1С. - Проблема, как найти идентификаторы объектов конфигурации 1С, решилась выгрузкой конфигурации в XML. Предварительно файл cf был выгружен с помощью Tool 1CD и загружен в чистую базу на SQL.
- Далее путем поиска таблицы в DBNames получаем её идентификатор, и ищем по нему в каталоге с выгруженной конфигурацией XML. Находим, удаляем объект в конфигураторе, снова попытка сохранения – другая ошибка, на другую таблицу… в общем повторяем итерацию в надежде вылечить базу до тех пор, пока не получаем вот такую ошибку:
- И это серьезная засада, потому как непонятно что ещё можно удалить из конфигуратора. Можно конечно запустить Profiler и найти на какую таблицу он ругается. Но в конце концов это всё закончилось такой ошибкой на поле Fld793 (ОбластьДанныхОсновныеДанные), и по профайлеру всё останавливается после проверки таблицы журналов и всё, вылетает.
- В итоге приходим к выводу, что «скотчем и соплями» проблему не решить, и придётся подходить к вопросу системно.
Инструментарий
- Загрузка/выгрузка данных из DBSchema и DBNames(используя алгоритм Deflate);
- Загрузка схемы объекта из чистой эталонной базы, автозамена реквизитов объекта на наши. Добавление/замена схем объектов в DBSchema;
- Проверка и автоматическое(не все) создание недостающих схем объектов, проверка реквизитов в таблице DBNames;
- Реструктуризация таблиц SQL, добавление/замена полей(не все);
- Загрузка в таблицы SQL, выгруженные из файловой базы с помощью Tool 1CD
upd. 2024.07.13 — Добавлена интеграция с обработкой //infostart.ru/public/275315/. Подключаемся к "убитой" базе, читаем список таблиц и загружаем напрямую нужные таблицы в SQL
Причины купить
Экономия собственного времени на решение подобной задачи
Достоинства
Обработка предназначена ТОЛЬКО для программистов 1С. Написана под конкретные проблемы конкретной базы. Автоматически восстанавливаются схемы Справочников, Документов, Журналов документов, Регистров сведений, Регистров накопления, Констант, Перечислений, Регламентных заданий… остальные объекты править ручками, либо писать код по аналогии с моим.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
))
Должен быть чек-лист по обновлению!
(1)
Да ее на SQL, где это займет не более 10-20 минут.
В 7ке DBF при обновлении и реструктуризации бакап формировался платформой на каждый файл отдельно.
Неужели сложно было встроить в платформе бакап базы при реструктуризации куда нибудь во временную папку?
«Если звезды зажигают значит это кому нибудь нужно» (с)
с помощью GameWithFire ( ) ?
(4) Спасибо за ссылку! К сожалению, сам найти не смог подобного решения.
Ничего не понял. Вы базу восстановили? Если есть CF такой же точно конфы, то почему бы просто не подменить одно значение из DBSchema ?
(6) Базу конечно же восстановил. В каждой базе DBSchema генерируется свой, т.е. даже если выгрузить CF из таблицы Config и залить в новую чистую базу — имена таблиц и полей будут каждый раз разными. Поэтому приходится брать из чистой базы из DBSchema схему объекта, и выполнять в ней замену имён полей на имена «убитой» базы. Особую сложность в этом процессе представляют индексы.
На что тогда вы опирались, при лечении DBSchema, если CF и в битой базе, и в любой другой, созданной на основе оригинального CF, будет таким же (т.е. таблица Config) ?
Из CF нам нужны идентификаторы объектов и реквизитов метаданных. По ид получаем из DBNames имена полей. Т.е. получив схему объекта из чистой базы, мы можем через DBNames чистой базы получить имена реквизитов. Далее обратная процедура, берем DBNames «убитой» базы и определяем её имена полей.
Напишите пожалуйста документацию к обработке. Кнопок много. Какова правильная последовательность действий? И назначение кнопок не всегда ясно.
Собственно я уже отметил, что обработка является «инструментом» программиста, по аналогии например с 1cadmin. Весь функционал заточен на понимание проблемы, и методики её решения самим разработчиком. В каждом конкретном случае приходится что-то в ней допиливать или менять. Сейчас у меня есть несколько восстановленных баз с её помощью, и каждый раз что-то я допиливаю или переделываю. Если есть конкретные вопросы — велком в личку, с удовольствием подскажу/объясню.
Использовал Вашу обработку в своей . Полагаю, что для Вас основная ценность обработки именно в автоматическом поиске и исправлении ошибок. Полагаю, коллегам пригодилась бы урезанная версия, с функционалом только в части выгрузки DBSchema и DBNames из sql в файл и обратно, за меньшую цену sm.
Выгрузку/загрузку можно сделать отдельной обработкой, я в своей использовал наработки также других товарищей с инфостарта. Постараюсь сделать упрощенный вариант и выложу за «мзду маленькую».
Насчет вашей методики восстановления, мне кажется, что можно было сделать проще. В обработке есть функционал генерирования объектов DBShema по данным копии конфигурации базы. Просто нужно реальную ситуацию смотреть, а не готовый вариант решения проблемы.
Благодарю. Обработка помогла. Статья пояснила как ей пользоваться, дав решение проблемы в «ручном» режиме . Из обработки видно что её функционал могуч и позволил бы сделать всё быстрей, но без мануала овладеть им явно сложнее чем ручками записи поправить. Если бы Вы автоматизировали то что проделал автор статьи могли бы поднять стоимость и повысить привлекательность для широких масс Вашей обработки.