Предистория:
Очередное динамическое обновление файловой базы данных ничего не предвещало плохого. Как вдруг выскочило окно «ошибка кэша…». 🙂 или просто завис конфигуратор во время обновления.
На первый взгляд ничего страшного: ну не сохранилась конфигурация в базе данных, снова откроем конфигуратор и обновим базу данных. Но не тут-то было…
В ответ на вопрос хотим ли мы повторить обновление 1С благополучно падает и не поднимается. Вот здесь начинаешь подозревать что-то неладное. Пробуешь еще раза три…тоже самое. Хуже того пользователи тоже не могут входит в базу данных с сообщением «Завершить» или «Перезапустить».
Тут включается мозг и вспоминаешь: есть же еще утилита для проверки файловой версии «chdbfl.exe«, но как ни странно утилита сообщает что ни одной ошибки нет, но база все равно не открывается. Запуск 1С из коммандной строки с параметрами: /UpdateDBCfg, /RollbackCfg или /IBCheckAndRepair -Rebuild — тоже не исправляют ситуацию…
Поиском по интернету и по сайту infostart нашел решения только для клиент-серверной (SQL) версии базы данных:
Смысл в котором заключается в удалении пары строчек из таблицы Config, но как удалить в файле *.1CD???
Решение:
С помощью программы Tool_1CD, которая позволяет просмотреть структуру и содержимое таблиц 1CD, нашел, что в таблице «Config» присутствуют строки со следующими значениями в колонке «FileName»:
сommit
dbStruFinal
DynamicallyUpdated
dynamicCommit
Опытным путем, было установлено что важными являются строки: «сommit» и «dbStruFinal» — их нам и надо удалить.
Если бы программа Tool_1CD еще бы позволяла редактировать — цены бы ей не было… А так пришлось экспериментировать…
Можно воспользоваться либо любым Unicode-редактором, либо HEX-редактором с поиском по Unicode.
Я использовал программу HxD (т.к. она позволяет быстро работать с файлами большого объема). Открываем файл *.1CD. В меню выбираем поиск, ставим обязательно галку «Юникодовая строка» и вводим в поле «Искать» слово «сommit».
Программа находит нужную строку. Но удалять нельзя, т.к. измениться смещения всех других объектов в файле. Тогда заменим первую букву этого слова на любую другую, например, «b»(«63» заменить на «62»).
То же самое проделать со словом «dbStruFinal».
Закрываем и сохраняем файл, запускаем 1С и, ура, база начала открываться.
Буду рад, если кому-нибудь сэкономил нервы и время…
P.S.: все это применимо только для после ошибки динамического обновления и если утилита «chdbfl.exe» показывает, что нет ошибок
Только недавно с таким боролся… Положили 17-гиговую базу… Интересно, что «падают» платформы версии 8.2.15 и 8.2.16, а после пробы на 8.2.14 обновление успешно завершилось и база стала работоспособна…
Правда ненадолго — через пару дней от того же динамического обновления опять легла — уже было хуже: «Ошибка считывания вторичной информации». Не восстановил. Так что, лучше юзайте SQL…
Плюсую за волю к победе!
Видимо резервной копии то и не было 😉
Она поди надежнее, чем пляска с коробкой динамита!
(3) program_km, автор же уточнил, что утилита ошибок в структуре не нашла.
(0) спасибо, берем на заметку!
Был такой случай. Помогло выполнение обновления через CF, а не через CFU. правда в дальнейшем, при попытке обновления через CFU ошибка повторялась.
Был подобный случай. Сделал следующее: Перенес CD-шник на другой компьюер, с другой платформой, обновление прошло, вернул назад.
Но так и не понял такой вариант — это частный (конкретный) случай или универсальный и проходит всегда.
Танцы с бубном )))) А пообщаться с «1С» не пробовали? Поменяли символы — это считается решением?
Надо же понимать что и где меняете.
сам недавно так же решал проблему. только я проставил нули в секции commit. после этого база запустилась
потом добавил новый справочник и это позволило дообновить базу. Ваше решение элегантнее =)
(5) MAXXL,
при данной проблеме не дает зайти в конфигуратор, поэтому обновить ни через cf ни cfu не получится
(6) Воронкин,
пробовал, на компе с другой платформой (посвежее) тож ничего не получалось
(7) GoodZone,
все он знал где и что менять. утилитой Tool_1CD посмотрел битую и рабочую базу из архива и увидел, что секции commit в рабочей базе нет. следовательно это и есть корень зла =)
Удивительно! До вашей статьи считалось, что ошибка динамического обновления не затрагивает файловые базы. В том числе на партнерском форуме об этом писали.
PS/ Архивную копию нерабочей базы сделали для истории?
Спасибо огромное за решение проблемы)) Позавчера у меня файловая база полетела с теме же симптомами.
Испробованных chdbfl.exe и запуск 1С из командной строки с параметрами: /IBCheckAndRepair -Rebuild — тоже не исправили ситуацию.Так как база была копией филиальной- для просмотра, пришлось попросить выслать ее копию.
Но копия покалеченной базы у меня осталась, на ней и воспользовалась вашим советом. сommit нашла и подменила первую букву, а строка dbStruFinal не нашлась. В итоге база запустилась с предложением преобразования на новую платформу))
(2) Ре(2) automatizator,
Резервная копия была, но проблема обнаружилась к концу дня, а было это начало месяца, в базу было столько документов набито, что восстанавливать их уйдет еще день с лишним, а надо сдавать отчеты
(7) GoodZone,
Меняем Идентификатор строки в Config c commit на bommit например, чтобы конфигуратор не нашел этой строки и открылся нормально
После этих изменений думал что с конфигурацией будут какие-нить проблемы — нет все работает, сохраняется и даже изменения сделанные перед сбоем сохранились
(10) bforce,
Тоже думал, что на файловой такое не может случиться — все таки другая система хранения данных (недавно только на SQL-базе восстанавливал). Но 1С решила не делать исключений для файловой версии 🙂
Был точно такой же случай. Благо клиент обновлял базовую версию программы автоматическим обновлнием, при котором программа сама создает архивную копию в папочку Temp. Возьму этот способ восстановления себе на заметку, на всякий случай.
(9) Наоборот — платформа была очень старая, а на такой-же и посвежее — первый раз не получилось
(10) Теория это одно — а на практике получается по другому.
Недавно тоже боролась с такой шнягой….страшно было жуть(база 26г), пришлось востановить config. Статья очень полезная. молодец.
Тоже не так давно была подобная проблемка, восстановил с копии,
а с битую базу сохранил — сейчас помучаю!
Автору респект!
Господа в топку динамическое обновление от 1с. Они его уже 5 лет не могут сдеать, кривожопорукие.
да динамическое обновление это зло.Риб не любит динамичское обновление.При создании 2 распределенной базы идет ругань пока не переобновишь конфигурацию не динамически.Так что поддержу в топку динамическое обновление.Люди никогда не пользуйтесь им.
(0) Вместо поиска строки (а вдруг такая строка найдется в другом месте базы?) можно просто включить в Tool_1CD отображение адресов записи и сразу увидеть адрес, по которому нужно править.
(20) awa,
1)Таблица config размещается всегда в начале файла поэтому первым найдется нужная строка
2)А вы пробовали найти строку с commit в программе Tool_1CD? Кроме как перемещением слайдера больше никак не получиться, поиска и сортировки по Modified — НЕТ.
3)По адресу поподаем чуть раньше этого слова
(21) Хм.
1) Таблица CONFIG размещается в начале базы как правило, но не всегда. Более того, она может быть фрагментирована, и блок именно с commit может оказаться ближе к концу файла 1CD.
2) Конечно, пробовал. Промотать до конца всех записей, начинающихся на «c» и перед началом записей на «d» — совсем не трудно. Главное, отсортировать по имени, по умолчанию, эта сортировка и включается.
3) Конечно, чуть раньше. Адрес записи указывает на признак удаленности записи, это будет байт 00 (удаленная запись — 01), потом идут 2 байта длины имени (для «commit» это будет 06 00, естественно), и затем уже идут сами байты юникодной строки. Из этого следует, что достаточно поменять по адресу, отображаемому Tool_1CD байт с 00 на 01, чтобы пометить на удаление запись.
спасибо автору за труд в его статье , хоть данный метод уже как баян, но будет новичкам как методичка)))
+ за это,
Минус можно ставить , так как не понятно на сколько данный метод безопасен) хоть база уже и «положена» но могут сделать еще хуже))
Не понятно как выбирать эти байты, в слепую удалять тоже не хочеться ))))))
Все равно спасибо автору
Вот если бы кто-нибудь сваял и выложил автоматический патчер для таких битых баз на основе опубликованной автором методики — было бы здорово!
Можно было бы сразу использовать его в случае, когда chdbfl не помогает поднять базу, а не заниматься воспоминаниями на тему «блин, где же я видел методику восстановления»… ))
(22) awa,
>вдруг такая строка найдется в другом месте базы
В теории конечно, но не все так хорошо знают структуру как Вы. Можно использовать смещение адреса. Но на практике я не видел ни одного случая чтобы это имело место. Поэтому как дополнение можно использовать. Но следуя Вашей логике: а почему надо удалять именно строку с «commit»?. Это также было определено практически и это работает. В теории на вопрос: «…произошла ошибка. Повторить обновление?» должна была обновиться база и запуститься. А на практике несколько десятков пользователей сидят без дела и ты думаешь откатываться тебе до резервной копии и потерять день с кучей документов в начале месяца или все таки попробовать восстановить базу….Легко рассуждать сидя за кружкой пива ( 🙂 не в обиду…)
(24) vvr908,
Я думаю это будет не всегда и с последующими релизами они это поправят. А универсального патча на все случаи жизни не придумаешь…
А что обязательно обновлять именно динамически? Есть либо утро, либо вечер (что хуже, ибо юзвери сидят до конца) — и обновляй на здоровье, не рискуя.
Столкнулся с такой ошибкой, поправил — вошел в конфигуратор. Вопрос. Как теперь выгрузить конфигурацию? При выгрузке ругается на файл «bommit», естественно что у нас его нет))) Как удалить вообще эту запись? Нулями затереть или как?
(27) Dimasik2007,
Тест и исправление сделай или пересохрани конфигурацию в обычном режиме
Нулями не надо
Тест и исправление не помогли. Что значит «пересохрани конфигурацию в обычном режиме»? Это как?
Могу даже подсобить 🙂 вот вам vbs скрипт всем известный:
File=»1Cv8.1CD»
тут я заменил под commit из картинки, надо сделать еще один скрипт для dbStruFinal
arr =split(«00 63 00 6F 00 6D 00 6D 00 69 00 74″,» «)
А сюда пихаем то, на что хотим заменить. Учтите, все на нули менять нельзя, можно например на 20 поменять, т.е. в итоге выйдет строка типа 00 20 00 20 00 20 00, что соответствует пустому значению, но без здвига. Так же и удаляют информацию о пользователях, получая полный доступ к базе данных :).
arr2=split(«00 62 00 6F 00 6D 00 6D 00 69 00 74″,» «)
for each c in arr
r=r & chrb(clng(«&H» & c))
next
for each c in arr2
r2=r2 & chrb(clng(«&H» & c))
next
set s=createobject(«ADODB.Stream»)
s.type=2
s.open
s.loadfromfile(File)
ss=s.readtext
s.position=0
s.writetext(replace(ss,r,r2))
s.position=0
s.type=1
s.position=2
ss=s.read
s.close
s.open
s.write(ss)
call s.savetofile(File,2)
Сохраняем как в файл с любым именем и расширением *.vbs, копируем в папку с файловой базой и запускаем.
Не тестировал, ибо не на чем. Кто может — протестите и выложите готовый скрипт
(29) Dimasik2007,
Измени что-нить в конфигурации (например, создай реквизит и удали) и сохрани, не динамически
Делал, и реквизит, и справочник — нифига) Пришлось копипастить, благо изменений не много было.
(32) Dimasik2007,
У мне проблем с сохранением не было. Сразу как вошел сделал выгрузку, тест и исправление, и сохранил конфу — все прошло нормально
Большое спасибо! Очень интересный и позновательный материал!
Спасибо за полезную информацию, надеюсь не пригодится
Хм… А я после сбоя динамического обновления файлы кеша 1С чистил и все работало…
Молодец чувак. Полезная информация. Я бы после такого эксперимента, всякий случай, сделал бы перенос данных на аналогичную конфигурацию. И с ней бы уже работал. Но возможно это лишнее ).
(7) GoodZone,
это все круто — написать в 1С, дождаться ответа, сделать…
Особенно можно не спешить, когда сидишь у клиента, отчетность какая-нибудь — да и фиг с ней. Надо делать так: восстанавливаешь из копии и с невозмутимой мордой гришь — у вас база битая, приду, когда из 1С ответят
Автору спасибо. Ценная инфа.
Попробовал решить проблему через WinHex. Строк «commit» и «c o m m i t» не нашел, так же как и «dbStruFinal».А ошибка именно как в статье. У кого то получалось? Или не получалось? Отзовитесь — может это не панацея?
(40) CaSH_2004, галку «Юникодовая строка» не забыл поставить,
если не забыл, то посмотри с помощью Tool_1CD, правда придется искать по алфавиту ручками
Юникод вобще-то там выбирается в списке, а не флажком. Конечно выставил — не в первый раз работаю с ним. Вобщем решил проще — т.к. можно было зайти в режиме Предприятие хотя и ругалось на необновленную конфу, но когда делаеш повторно обновление он делает выгрузку — а она получилась вполне живой. Я ее загрузил в пустую базу и откатился к базовой конфе, после чего обновил повторно. Все заработало.
Так что может зря эти танцы с бубном? Хотя на большой базе наверно долше будет.
(42) CaSH_2004, у тебя другой случай — у тебя конфигуратор открывается и можно базу выгрузить…
(43) В том то и дело что в Конфигуратор не пускало с ошибкой потока. Перенос на другой ПК или chdbfl — не помогли. Заходить можно было только в Предприятие.
Удивительно что сам механиз динамического обновления умудрился сделать выгрузку в DT! Подозреваю что он делает это не типовыми средствами — что наводит на подозрительные мысли…
Спасибо за инструкцию, если бы не вы мне была бы крышка! Ситуация такая-же при динамическом обновлении, завис и выкинуло из конфигуратора, а потом не открывается. Спасибо помогли!
Еще один момент: после того как восстановили работоспособность базы, необходимо сделать выгрузку/загрузку, т.к. могут возникнуть глюки с обновлением конфигурации
(40) CaSH_2004,
Мне помог вариант с использованием предыдущего релиза платформы. Открыл неработающую в 15-16 платформах базу 14-й платформой, накатил обновление, выгрузил, загрузил. Выдохнул =)
Ждем новых кроликов-тестеров платформы 8.3, в которой якобы можно изменять структуру метаданных на живой базе с работающими пользователями =)
(0) автор, никакое это не «восстановление», а разлочивание залоченной базы после динамики..
Уберите тему, или назовите нормально.
А то начнут «восстанавливать» подобным образом.
(49) С чего Вы взяли, что Ваша терминология правильная, а у автора статьи неправильная? В статье описана ситуация, когда ДО база не работает, а ПОСЛЕ работает. Вполне себе подходит под термин «Восстановление работоспособности файловой базы». А вот назвать данную ситуацию «база залочена» (по-русски правильнее все же «заблокирована») я бы не решился. Никто и ничто тут базу не блокирует, здесь налицо ошибка 1С, но не блокировка.
(49) AlexO,
«разлочивание залоченной базы после динамики» — Интересно кто может в поиске такую строку задать?
Повторюсь: когда база не поднимается и над тобой висят пользователи, руководство, телефон обзвонился, клиенты ругаются… то у тебя одна только мысль: «как восстановить базу…».
Согласен с (50). Мне думается так понятнее большинству участников форума.
Спасибо автору! очень помогла информация!
Спасибо большое помогло для восстановления БД, открыли поправили удалили и база снова в норме, благо автору.
Спасибо, спасибо, спасибо!!!
Насчет релизов платформы. Посмотрели программисты из 1С, что с падением при динамических обновлениях РИБ разобрались, и добавили в новой платформе баг-фичу с падениями и без РИБ — в клиент-серверном варианте. Потом нашел хороший человек выход и из такого положения, тогда суровые программисты из 1С добавили начиная с 15й версии: падения в файловых базах… боже, что же они дальше добавлять-то будут?..
ТС спасибо.
Большое спасибо за текст. Теперь динамически больше обновлять не стану, от греха по дальше.
Спасибо за статью. Метод подошел, несмотря на другие условия возникновения проблемы. Ошибка возникала при ночном сбросе сессии в момент реструкторизации. После в конфиг не пускало с аналогичной описанной в теме проблемой ( 15 платформа), chdbfl уходил в ошибку. Исправление commit помогло.
мда, чем только 1с баги не порадують…
(50) awa,
Как раз блокирует. А не снятый флаг — это ошибка, но не «восстановление базы».
Спасибо очень помогла информация!
Автору респект.
Восстановил таким образом работоспособность БД.
Дай Бог тебе здоровья!
Помог
Спасибо большое за информацию!
Тоже все получилось!
Спасибо Огромное!
Про лечение в sql версии читал — но что такое возможно на файловой не думал — пока не столкнулся, а вот на счет hex редактора не додумался.
Спасибо огромное!
Очень помогла Ваша публикация!
Поднял базу!. Подтверждаю, что это работает и на платформе 8.3.10.
Нашел только commit и его изменил, этого оказалось достаточно.
(67) Очень рад за вас, хотя сам такую проблему давно уже не встречал…
Спасибо, помогло восстановить базу!
Сергей, спасибо, что Вы есть ! Дай бог тебе здоровья и всего остального.
Несколько часов маялся, помог Ваш отличный совет, правил строчки правда прям из tool_1CD (у меня редактирует и удаляет)
Благодарность Вам преогромная, прямо спасатель Вы!
Для 1С:Предприятие 8.3 (8.3.10.2650) помогло. Спасибо!
Слава Богу! Помогло! Нашел c.o.m.m.i.t.? поменял как сказано «c» на «b», и, о чудо, заработало! Второе слово не нашел, да и первое нашел с трудом по первым трём буквам. Но и этого хватило. (Бух.предпр.2.0.55.7). Храни вас Бог. Многая и благая лета вам.
(70) Поделитесь пожалуйста Tool_1cd, который редактирует и удаляет, если это не нарушает ни чьих прав.
Была такая ошибка после динамического обновления. База была УПП 1.3, платформа 8.3.10.2667
Размер базы 34 Гб.
Не получалось зайти ни в конфигуратор, ни в пользовательский режим.
Получилось зайти в конфигуратор платформой 8.3.13.1865. В этот момент все пользователи уже вышли. Все дообновилось.
(75) Есть разные варианты падения… Тоже думал, что на новых релизах такого бага уже не будет… Неделю назад при динамическом обновлении sql-версии базы произошла такая ошибка , причем при запуске конфигуратора выдает сообщение: «При обновлении произошла ошибка. Повторить?»… «Перезапустить». Но при перезапуске всё тоже самое… Пришлось вручную ремонтировать.
Заметил, что баг возникает когда идет динамическое обновление и при этом заходит в базу какой-нить из пользователей.
(73) Рад, что помогло…) Второго слова может и не быть… всё зависит в какой момент упало….