Ошибка СУБД. Внутренняя ошибка компоненты dbeng8.
Платформа: 1С:Предприятие 8.2 (8.2.14.540)
Конфигурация: Бухгалтерия предприятия, редакция 2.0 (2.0.31.7) локальная версия на 1 пользователя.
Столкнулась впервые с такой проблемой. Хотелось бы знать от чего она могла произойти и что это за ошибка.
Комп старый и древний, периодически на нем бывают всякие проблемы. В этот раз пользователь работал с базой, вводил документы, вдруг комп написал (как мне пользователь сказал), что не достаточно памяти и перезагрузился. 1С открылась, еще работала еще какое-то время, потом опять начало то 1Ску выбивать, и приходилось ее открывать заново, то комп начинал вдруг перезагружаться. И вот закончились эти мытарства тем, что при попытке создать и провести новый документ или операцию, или перепровести старый, при нажатии на кнопку ОК комп просто напрочь зависал и так висел пока не снимешь задачу через диспетчер задач. Позвали меня. Я убедилась, что висит прочно комп, в диспетчере увидела, что процесс 1cv8.exe от пользователя запущенныйзагружает на 99% ЦП. Сняла процесс, при попытке протестировать эту базу через конфигуратор комп опять вис или перезагружался.
Конфигурация: Бухгалтерия предприятия, редакция 2.0 (2.0.31.7) локальная версия на 1 пользователя.
Столкнулась впервые с такой проблемой. Хотелось бы знать от чего она могла произойти и что это за ошибка.
Комп старый и древний, периодически на нем бывают всякие проблемы. В этот раз пользователь работал с базой, вводил документы, вдруг комп написал (как мне пользователь сказал), что не достаточно памяти и перезагрузился. 1С открылась, еще работала еще какое-то время, потом опять начало то 1Ску выбивать, и приходилось ее открывать заново, то комп начинал вдруг перезагружаться. И вот закончились эти мытарства тем, что при попытке создать и провести новый документ или операцию, или перепровести старый, при нажатии на кнопку ОК комп просто напрочь зависал и так висел пока не снимешь задачу через диспетчер задач. Позвали меня. Я убедилась, что висит прочно комп, в диспетчере увидела, что процесс 1cv8.exe от пользователя запущенныйзагружает на 99% ЦП. Сняла процесс, при попытке протестировать эту базу через конфигуратор комп опять вис или перезагружался.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) ediks,
Спасибо за оперативный ответ. Вот я подозреваю, что на том ПК что-то с диском, т.к. уже было, что он перезагружался, наверно планирует навернуться жесткий диск. Аж страшно туда возвращать базу 1С-ки после таких ошибок. Или ничего не будет страшного? На всякий случай, попрошу руководство отдать копм на тестирование программистам. Ну в чем-то же должна быть причина?
Спасибо за оперативный ответ. Вот я подозреваю, что на том ПК что-то с диском, т.к. уже было, что он перезагружался, наверно планирует навернуться жесткий диск. Аж страшно туда возвращать базу 1С-ки после таких ошибок. Или ничего не будет страшного? На всякий случай, попрошу руководство отдать копм на тестирование программистам. Ну в чем-то же должна быть причина?
Свободного места на диске полно, больше 20 гб.
Вобщем, сделала я следующее, пришлось эту базу перенести на другой комп, там открыла в конфигураторе, начала тестирование и исправление, выдал ошибку:
"Ошибка СУБД:
Внутренняя ошибка компоненты dbeng8"
и все, и ни в какую не хотел дальше тестировать. Повторила несколько раз, ничего. Запустила просто тестирование, без исправления, выдал ошибки:
"В таблице AccRg443 не верны 11 записей.
В таблице AccRg479 не верны 25 записей.
В таблице DocumentJournal5547 не верна 1 запись.
В таблице AccumRg7282 не верны 4 записи."
После того, как нашлись ошибки, я запустила опять тестирование уже с исправлением. И прога выдала следующее:
"В таблице AccRg443 удалены 11 записей.
В таблице AccRg479 удалены 25 записей.
В таблице DocumentJournal5547 удалена 1 запись.
В таблице AccumRg7282 удалены 4 записи.
ну, и что все объекты перезаписаны, база реструктуризирована и т.д. вобщем, как обычно пишет"
После этого запустила базу в режиме исполнения, вроде нормально документ и операция вручную у меня записались и провелись, пользователь еще не работал с базой. Можно надеяться, что ошибки устранились и в базе все стало нормально? Или еще что-то надо сделать, может что-то проверить надо? И вообще из-за чего такие ошибки возникли? Могли появиться из-за проблем того ПК? Я не большой специалист в области программирования или администрирования 1С, просто уверенный пользователь, так что, не судите строго.
Вобщем, сделала я следующее, пришлось эту базу перенести на другой комп, там открыла в конфигураторе, начала тестирование и исправление, выдал ошибку:
"Ошибка СУБД:
Внутренняя ошибка компоненты dbeng8"
и все, и ни в какую не хотел дальше тестировать. Повторила несколько раз, ничего. Запустила просто тестирование, без исправления, выдал ошибки:
"В таблице AccRg443 не верны 11 записей.
В таблице AccRg479 не верны 25 записей.
В таблице DocumentJournal5547 не верна 1 запись.
В таблице AccumRg7282 не верны 4 записи."
После того, как нашлись ошибки, я запустила опять тестирование уже с исправлением. И прога выдала следующее:
"В таблице AccRg443 удалены 11 записей.
В таблице AccRg479 удалены 25 записей.
В таблице DocumentJournal5547 удалена 1 запись.
В таблице AccumRg7282 удалены 4 записи.
ну, и что все объекты перезаписаны, база реструктуризирована и т.д. вобщем, как обычно пишет"
После этого запустила базу в режиме исполнения, вроде нормально документ и операция вручную у меня записались и провелись, пользователь еще не работал с базой. Можно надеяться, что ошибки устранились и в базе все стало нормально? Или еще что-то надо сделать, может что-то проверить надо? И вообще из-за чего такие ошибки возникли? Могли появиться из-за проблем того ПК? Я не большой специалист в области программирования или администрирования 1С, просто уверенный пользователь, так что, не судите строго.
У меня такая же ошибка выскакивала при попытки записать приходный кассовый ордер в УТ 10.3, помогло тестирование и исправление.
У меня похожая беда, но при групповом перепровелении ( востановленнии последовательности) вылетает только на документах за крайнюю дату ............... так что всетаки поможет? chdbfl?
chdbfl исправляет нарушение физической целостности, ТиИ проверяет внутренние нарушения (ссылочную и логическую целостность)
поэтому в первую очередь chdbfl, а потом ТиИ
а комп на вирусы прогнать не мешало бы
поэтому в первую очередь chdbfl, а потом ТиИ
а комп на вирусы прогнать не мешало бы
"После того, как нашлись ошибки, я запустила опять тестирование уже с исправлением. И прога выдала следующее:
"В таблице AccRg443 удалены 11 записей.
В таблице AccRg479 удалены 25 записей.
В таблице DocumentJournal5547 удалена 1 запись.
В таблице AccumRg7282 удалены 4 записи.
ну, и что все объекты перезаписаны, база реструктуризирована и т.д. вобщем, как обычно пишет" "
а теперь пусть пользователь проверит осв и прочие отчеты на предмет сохранности данных
"В таблице AccRg443 удалены 11 записей.
В таблице AccRg479 удалены 25 записей.
В таблице DocumentJournal5547 удалена 1 запись.
В таблице AccumRg7282 удалены 4 записи.
ну, и что все объекты перезаписаны, база реструктуризирована и т.д. вобщем, как обычно пишет" "
а теперь пусть пользователь проверит осв и прочие отчеты на предмет сохранности данных
Я в такой ситуации сделала ТиИ с реструктуризацией таблиц и chdbfl, честно говоря, не помню, что именно помогло.
Спасибо помогло. При тестировании в конфигураторе тоже получал ошибку, запустил утилиту chdbfl, потом снова тестирование в конфигураторе и уже норм отработало.
Я бы порядок действий поправил:
1) проверить диск на наличие битых кластеров
2) проверить свободное место на диске
3) протестировать базу утилитой chdbfl
4) Конфигуратор -> Администрирование -> Тестирование и исправление ИБ
1) проверить диск на наличие битых кластеров
2) проверить свободное место на диске
3) протестировать базу утилитой chdbfl
4) Конфигуратор -> Администрирование -> Тестирование и исправление ИБ
Я бы в порядок действий добавил (учитывая, что комп старый):
0)Отдать комп на ТО (предварительно скопировав базу в укромное место).
- Зачастую причиной перезагрузки бывает банальная пыль в системном блоке. Много пыли -> процессор (память / контроллеры) греются -> комп глючит и перезагружается.
- Также одна из причин - старение электронных компонентов как блока питания, так и системной платы - не держат допустимые параметры (напряжения / емкости). Наскоро можно попробовать поменять блок питания.
0)Отдать комп на ТО (предварительно скопировав базу в укромное место).
- Зачастую причиной перезагрузки бывает банальная пыль в системном блоке. Много пыли -> процессор (память / контроллеры) греются -> комп глючит и перезагружается.
- Также одна из причин - старение электронных компонентов как блока питания, так и системной платы - не держат допустимые параметры (напряжения / емкости). Наскоро можно попробовать поменять блок питания.
У меня была подобная проблема. Пробывал ТиИ на старом и на новом компах - платформа падала. Помогла только утилитка chdbfl.exe
Очень часто такая беда происходит, когда в локальной сети с базой работают клиенты, соединенные через WiFi.
(23) noname1980, <quote>притом на 5 гиговой базе достаточно быстро, за 1.5 часа</quote>
Вы знаете толк в извращениях ;) На таких объемах стоит переходить на клиент-серверный вариант. Либо, если 5 гигов - результат накопленной истории, резать базу.
Вы знаете толк в извращениях ;) На таких объемах стоит переходить на клиент-серверный вариант. Либо, если 5 гигов - результат накопленной истории, резать базу.
не помогает , у меня такая ошибка возникает при начале автоматического обмена связи с FTP , под админом все работает , тестирование и исправление запускаю -ошибка ФАЙЛ БД поврежден
Смотрю довольно часто такие ошибки бывают. Мы в процессе последующей эксплуатации системы еще несколько раз с таким сталкивались. Всегда chdbfl.exe и ТиИ через конфигуратор помогало корректно все исправить.
Такая же ошибка была при попытке редактирования свойств пользователя через конфигуратор (при этом непонятно что произошла с базой, т.к. винт целый, сервак новый, никаких лагов в последнее время не было). Опять-таки и в этом случае chdbfl помогла (ещё вычитала совет, что можно либо переустановить платформу, либо тупо заменить файл dbengs.dll - но не испробовала, т.к. помог первый вариант с утилитой 1с-ной).
(34) areavel, если конфигурация не совсем дохлая, то вернут доки не проблема: формируем оборотку в обеих (исправленной и бэдовой), смотрим где не сходятся остатки/обороты, а дальше в зависимости от количества доков или ищем просто по оборотке по счетам сравнивая,или, ещё проще зная в каких доках трабл, формируем список доков в первой и второй базах, выгружаем в Excel, сравниваем и вуаля. А дальше, опять-таки, зависит от количества "потеряшек": или ручками, или обработками их переносим в исправленную базу.
Но железо тут наверное, все-таки, тоже свою роль играет,на старом и на новом компе стоят 2 идентичные базы, на старом база постоянно сыпется, а на новом ни разу не было.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот