Формат файла ibparams inf не совпадает с ожидаемым
gai163, в техподдержку звонили? вообще по слухам 64 бит нерабочая пока что. может конечно что-то поменялось. странно что вы ее вообще скачали.
в том-то и дело, что не работает. Обновился через менеджер обновлений. Региональный представитель отправил запрос разработчикам, но ответа пока нет. Я что, один такой?
64-разрядная версия проходит этап опытной эксплуатации и всем подряд не ставится, только желанию. при этом в обязательном порядке передается и обычная 32-разрядная сборка, т.к. в ряде случаев, а у вас это и случилось, возможны нештатные ситуации. причина возникновения вашей ошибки найдена и находится в стадии исправления. в следующем релизе все будет работать.
Спасибо за разъяснения. 32-х битная стоит. В ней и работаю. Просто не очень понятно, как удалось до 64 обновиться, раз это уникальный случай.
Интересно, 64 чем отличаться будет?
ничем, кроме возможности работать со сметами, в которых оооочень большой объем данных: 2-3тысячи позиций + более 50 актов, в которых свои индексы + свои цены. как правило, такие сметы при попытке открыть их в х32 выдают ошибку Out of memory.
Флеш-версия 8.0.2, ноут Lenovo 310-151.
На что грешить не знаю, но ситуация такая: в конце рабочего дня закрываю программу, смета на 11.280 млн., утром запускаюсь, открываю эту же смету, цена . 18 с лишним млн. . картина маслом, падаю со стула. Выясняется, в нескольких местах (флешка, а может бук) внес изменения в формулу, в результате песка вместо 24 м3 стало 2400 м3 (забыл разделить на 100, вернее вообще удалил деление на 100).
Эпизод второй: документы в Эксель, выводит ОБЯЗАТЕЛЬНО с 3-й попытки; первая попытка, он пишет, что не находит шаблон; вторая попытка, прога "ругается" и собирается отсылать письмо разработчикам; с третьей попытки, выводит и все последующие разы работает исправно. Следующий запуск проги, повторяем; нет шаблона, пишем письмо.
Еще одно недоразумение; вставляет скопированные строки, как-то не корректно, то вместо 6 строк, вставит 3, то начинает вставлять вообще из прошлого/позапрошлого копирования. Пару раз "обжегся", сейчас очень внимательно контролирую. что он вносит.
В общем на кого грешить, на флеш-версию или на ноут, пока не могу определиться. Пока сидел на 8.0.0, думал выйдет обновление, "детские болезни" излечатся, обновился, все осталось без изменения.
Сформировалось мнение, что это именно флешка "бычит" и надо "крутить" руководство на стационар, но поговорил с приятелем у которого стационар, правда 8.0.0, то же как-то невнятно .
Еще я был очень удивлен, приятно удивлен, что прога без каких-либо тормозов и вообще нареканий, "жевала" смету под 3 тыс. позиций, ни разу не сбоила и отработала на "отлично". (Разработчикам "уважуха").
Надо выбрасывать одно "слабое" звено !, но кто/что "слабое" звено, мы узнаем после рекламной паузы .
Если проблема имеет решение — то волноваться незачем, если решения нет — то волноваться бессмысленно.
добавьте программу в исключение антивируса.
+ добавьте папку со сметами в исключения.
учитывая, что у вас флэш-версия, вынимать ключ из компа надо строго через безопасное извлечение. в этом случае кэшированые данные будут (должны быть) записаны на флэшку операционной системой.
mtsn, Спасибо за подсказку. Стараюсь вынимать ключ только после выключения, бывают редкие исключения, не без этого. Про антивирусник, не знал.
С упрямой периодичностью на форумах по 1С появляются крики души "Помогите! Упала файловая база, бэкапов нет, что делать?". Лично я всегда при этом вспоминаю известную шутку "Админы делятся на два типа — тех, кто делает бэкапы, и тех, кто будет их делать". Но, отбросив шутки в сторону, постараемся серьёзно рассмотреть данную проблему, ведь ситуации бывают разные. Например, бэкапы делались на диск, на котором закончилось место, или бэкапы делались через выгрузку, и все такие выгрузки за последнее время оказались неработоспособны. К слову сказать, даже админы, считающие себя "бывалыми", прокалываются на подобных мелочах.
В качестве разминки, позвольте изложить несколько советов по правильной организации бэкапов файловых баз данных, несоблюдение которых может сыграть злую шутку:
1. Помимо настроенных автоматических ежедневных бэкапов, обязательно сделайте дополнительный бэкап перед такими критическими операциями, как обновление конфигурации, ТиИ, проверка базу с помощью chdbfl.exe и т.п.
2. Делайте бэкап архивированием (копированием) файла 1Cv8.1CD, либо комбинируйте копирование с выгрузкой в .dt. Ни в коем случае не ограничивайте бэкап только выгрузкой в .dt, ведь наличие некоторых ошибок в файле 1Cv8.1CD может привести к тому, что в выгрузке будет отсутствовать часть информации, либо выгрузку вообще невозможно будет загрузить. И если с 1Cv8.1CD можно "поколдовать" и попытаться выудить нужные данные, то в случае полностью отсутствующих данных уже ничего не сделаешь.
3. Процедуру создания бэкапа выполняйте в такой период, когда с базой не работают пользователи.
4. Периодически проверяйте наличие свободного места на устройстве, куда настроено автоматическое создание бэкапов.
5. Старайтесь размещать бэкапы не на том же компьютере, где расположена сама база, а на других компьютерах/хранилищах в локальной сети (например, если на компьютере испортится жёсткий диск, или проникнет вирус-шифровальщик, получим порушенные и базу, и бэкапы). Старайтесь также периодически размещать бэкапы на дополнительных (альтернативных) источниках, например, в облачном хранилище (dropbox, yandex disk и т.п.), или на флэшке.
Первоначальные действия для диагностирования таких случаев должны быть такими:
1. Обязательно делаем самый первоначальный бэкап нашей проблемной базы (до любых манипуляций с ней) копированием/архивированием файла 1Cv8.1CD, и убираем его в надёжное место, дабы случайно не повредить.
2. Пробуем войти в базу под другими пользователями.
3. Полностью очищаем кэш 1С (это можно сделать, например, простым удалением базы из списка, и добавлением её в список вновь, либо использовать утилиты типа http://infostart.ru/public/90572/ , либо удалить вручную http://help1c.com/faq/view/1267.html ).
4. Пробуем перенести файл базы на другой компьютер, и войти в базу там.
5. Прибегаем к помощи утилиты chdbfl.exe из поставки 1С:Предприятие, с установленной галкой "Исправлять обнаруженные ошибки".
6. Ещё можно попробовать открыть базу на более свежих релизах 1С, например, если работали на 8.2.15, то можно попробовать на 8.2.17.
Если все попытки ни к чему не привели, и мы можем констатировать факт, что база "мёртвая", то остаётся выбрать правильный вариант дальнейших действий. Вариант первый, банальный - отдать базу на ремонт специалисту - рассматривать не будем, здесь проблема из технической плоскости уходит в переговорно-финансовую. Вариант второй, нудный, длительный, и с сомнительным исходом - переслать базу в 1С, и ждать результата - тоже рассматривать не будем, хотите им воспользоваться - пожалуйста, но сильно надеяться на быстрое и положительное решение я бы не стал. Вариант третий - попробовать починить базу своими силами - как раз и является нашей темой.
Итак, Вы решили починить базу своими руками, и окунуться в самые дебри загадочного содержимого файла 1Cv8.1CD. Какие же полезные статьи и инструменты мы имеем на текущий день?
Этап 1. Обследование, определение проблемных мест.
Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.
1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".
Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.
Вместо "C:\1cv8logs" можно указать любую существующую папку, куда будут писаться логи, но лучше создать новую, пустую, чтобы не было проблем с записью логов.
(Подробнее про настройку ТЖ можно почитать, например, здесь: http://help1c.com/faq/view/464.html )
Далее, запускаем нашу проблемную базу в режиме конфигуратора, дожидаемся вывода окошка с ошибкой, или краха приложения, и сразу же идём изучать содержимое записанного лога (он будет в файле "1cv8_PID\МеткаДаты.log"). На следующие события и ошибки не обращаем внимания (их наличие является нормальным):
1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)
Теперь мы понимаем, что записи в ТЖ типа
означают чтение файла "ibparams.inf" из таблицы PARAMS.
Итак, анализируем файл лога. Например, если происходит "Ошибка формата потока", а в конце файла лога мы видим примерно следующее:
3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).
При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.
5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.
Загрузив нашу базу в систему restoration-base-1c8, мы можем исследовать список таблиц:
а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:
Просмотр записей таблиц, к сожалению, не реализован.
На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих разделах.
Файлы:
Обработки с поддержкой формата БД 8.3.8:
Обработки для обследования.zip
Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.
1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".
Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.
1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)
Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.
3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).
При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.
5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.
Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:
а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:
Просмотр записей таблиц, к сожалению, не реализован.
На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.
Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.
1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".
Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.
1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)
Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.
3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).
При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.
5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.
Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:
а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:
Просмотр записей таблиц, к сожалению, не реализован.
На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.
При попытке внести изменения в базу данных службы Power BI, например, добавив дополнительные таблицы в базу данных SQL, пользователи Power BI могут столкнуться с различными ошибками формата данных. Некоторые из ошибок включают DataFormat.Error: Мы достигли конца буфера или power bi dataformat.error внешней таблицы не в ожидаемом формате .
Если вы также обеспокоены этими ошибками Power BI, вот несколько советов по устранению неполадок, чтобы решить проблему с несколькими ошибками Dataformat.er.
1. DataFormat.Error: мы достигли конца буфера
Проверьте размер файла
- Если ошибка возникает при попытке импортировать данные из нескольких файлов одновременно, это может быть связано с проблемами с размером файла.
- Проверьте размер файла JSON, чтобы убедиться, что он не связан с размером вашего файла.
Подожди, подожди и подожди!
- Если это временная проблема, то нет смысла пытаться устранить проблему вне вашей зоны комфорта.
- Пользователи сообщают, что ошибка формата данных была устранена автоматически через день или два.
- Итак, обратитесь в службу поддержки Power BI, если проблема подходит к концу.
Если проблема не устранена, выполните следующие действия.
- Если вы делаете PowerQuery, попробуйте отказаться от него и настроить промежуточную таблицу в базе данных SQL, которая анализирует JSON с помощью T-SQL.
2. Power BI dataformat.error внешняя таблица не в ожидаемом формате
Сохраните файл в Excel
- Если вы пытаетесь использовать файл Excel, импортированный из стороннего программного обеспечения, такого как бухгалтерское программное обеспечение, то в нем могут быть незначительные ошибки схемы XML.
- Хотя эти ошибки могут игнорироваться приложением Excel, но это приводит к ошибке при использовании с Power Query.
- Одним из способов решения этой проблемы является открытие проблемного файла Excel в приложении Excel и его повторное сохранение.
- Теперь импортируйте тот же файл в Power Query и проверьте, не возникает ли ошибка снова.
- Это может занять много времени, если у вас есть много файлов для работы. Однако, в качестве обходного пути, вы можете решить проблему, пока не будет найдено надежное исправление.
Изменить тип в прикладных шагах
Если проблема не устранена, попробуйте удалить начальный измененный тип данных для даты из числа в текст.
Читайте также: