Неопознанная ошибка работы с файлом конфигурации

Обновлено: 07.07.2024

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

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

Чтобы научиться быстро исправлять ошибки в 1С необходимо изначально их проанализировать. Часто во всплывающем окне написана суть некорректного поведения, что помогает решить проблему.

Причины появления ошибки в 1С

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

Одна из самых частых причин нарушение работы связанна с компьютером, на который установлена база данных 1С. Рабочая область может автоматически закрываться из-за нехватки оперативной памяти на сервере. Все возникающие неисправности должны быстро устраняться. В противном случае есть вероятность потери данных.

Часто возникающие ошибки 1С

Все имеющиеся сбои выводят на экран разные уведомления. Одинакового текста не бывает. Чтобы проще ориентироваться, разделим существующие ошибки 1С на следующие пункты:

Недостаточно памяти.
Ошибка доступа.
Ошибка формата потока.
Ошибка СУБД: Файл базы данных поврежден.
Неправильное отображение блоков формы.
Внутренняя ошибка компоненты dbeng.
Dump при запуске.
Неверный формат хранилища.
Ничего не работает.

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

Недостаточно памяти

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

Пользователь может самостоятельно решить проблему с памятью. По умолчанию операционная система выделят фиксированное значение гигабайт на обслуживание приложения: 32 bit ОС – 2 Гб, 64 bit – 4 Гб.

Увеличить размер выделенной памяти можно вручную. Для этого запускается адресная строка (Пуск – Выполнить, вводиться фраза cmd). После нажатия «Ентер» достаточно ввести фразу bcdedit /set increaseuserva 4096 и подтвердить действие (клавиша «Enter»). Цифра 4096 – новый выделяемый объем «оперативки». Выполняется перезагрузка системы. Проблема должна быть устранена.

Ошибка доступа

Она возникает, если учетная запись не имеет достаточно прав. Проявляется при выполнении определенного действия, которое доступно только ограниченному кругу пользователей. Для исправления ситуации достаточно изменить роль выбранного профиля в конфигураторе (вкладка «Администрирование – Пользователи»). В некоторых случаях это увеличивает безопасность базы данных, если необходимо защитить файлы от изменения сторонними людьми.

Ошибка формата потока

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

Устранение подобной ошибки 1С выполняется простой чисткой кэша. Для этого необходимо перейти в папку, где хранятся временные файлы. В Windows 7 и выше она находится по адресу C:\Users\Username\AppData\Local\1C или C:\Users\Username\AppData\Roaming\1C. Для Windows ХР другой путь – Local Settings\Application Data\1C\. Все файлы, начинающиеся на 1cv8, кроме «1Cv8.1CD» полностью удаляются.

Если «Ошибка формата потока» возникает в процессе работы, то нужно провести тестирование (Администрирование – Тестирование и исправление), выбрать первые 2 галочки и запустить процесс.

Ошибка СУБД: Файл базы данных поврежден

Если всплывает информационное окно с подобной надписью, неисправность базы данных решается тестированием файла и всей информационной базы. Такое мероприятие может проводиться 2 способами:

Запуск утилиты chdbfl.exe. Эта программа предназначена для того, чтобы проверять целостность базы данных при совместном ее использовании с информационной базой. Данный метод хорош тем, что дает возможность решать сбои даже в тех ситуациях, когда конфигуратор запустить невозможно. Сначала выполняется резервное копирование информации. В папке, где установлен 1С (директория bin) находится файл chdbfl.exe. Он запускается, в окне прописывает путь к файлу базы данных и ставится галочка, чтобы провести исправление ошибок. Нажимается кнопка «Выполнить». После завершения процесса все должно заработать. Если нет – используется конфигуратор.
Через конфигуратор. Нужное окно вызывается после нажатия «Администрирование – Тестирование и исправление». На экране появляется форма, где выставляются галочки на следующе строчки: «Реиндексация таблиц…», «Проверка логической целостности…», «Проверка ссылочной…», «Реструктуризация таблиц…», «Тестирование и исправление» и 2 раза «Создать объекты». Нажимается кнопка «Выполнить». После завершения процедуры сбой устраняется.

Неправильное отображение блоков формы

Такая неисправность возникает от разных факторов. Чтобы привести программу к нормальной работоспособности, пользователю необходимо последовательно выполнить несколько команд. После проведения каждой проверяется устранение сбоя:

Если приведенные методы не помогают, рационально будет провести обновление платформы.

Внутренняя ошибка компоненты dbeng

Dump при запуске

Возвращение 1С в рабочее состояние проводится простым обновлением MS Visual Studio (Visual C++) и дополнительными манипуляциями. Чтобы отследить конкретный файл, в котором возникает ошибка, открывается «Просмотр событий». Для этого пользователь переходит в «Панель управления – Система и безопасность – Администрирование». С левой стороны раскрывается «Журнал Windows – Приложение».

На экране появляется список ошибок и точное расположение поврежденного файла. После установки новой версии MS Visual Studio (Visual C++) с папки System32 копируется одноименный файл dll и вставляется в папку платформы 1С. Проблема решилась.

Неверный формат хранилища

Ничего не работает

Если программа перестала нормально работать без видимых причин, значит пользователю придется самостоятельно искать неисправность. Для восстановления работоспособности базы данных проводятся следующие мероприятия:

чистится кэш;
открывается файл chdbfl.exe из папки установки приложения и выполняется исправление;
выполняется запуск «Конфигуратора» для тестирования и исправления сбоев;
обновление «1С».

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

3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.

Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:

S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

Нюансы: обратите внимание, что ”Стандартные проверки” платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.

1С:Предприятие 8.2. Лицензия на сервер (x86-64)

По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.

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

1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель “запрет на фоновые задания” в
момент создания базы.

Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском – вещь в себе – и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять – возможно проблема “уйдет”.

3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться “возврат” к предыдущему состоянию данных

4) снимаем базу с поддержки, выгружаем cf
убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение) убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение)

1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.

можно попробовать и более радикальный шаг здесь:
удаляем (в менеджмент консоли) в базе данных таблицу “config”
D_rop TABLE [dbo].[Config]

5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.

6) Ошибка :"Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005"

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

При эсклуатации баз данных 1С вы можете сталкнуться с такой ситуацией:

Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005

Признаки проблемы: нельзя выгрузить в dt

Внимание! Ошибок с кодом 80004005 уйма, более подробно классофикацию я описал здесь http://www.gilev.ru/1c/mssql/errsql.htm . Здесь же мы говорим именно о "неопознанной ошибке" :)

Сотрудники 1С рекомендуют решать проблему так:

Нюансы: обратите внимание, что "Стандартные проверки" платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.

Также с этой ситуацией пересекается следующая ситуация:

Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском - вещь в себе - и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять - возможно проблема "уйдет".

2. Перезапустить сервер

3) делаем бэкап средствами sql

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

4) снимаем базу с поддержки, выгружаем cf

убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем "загрузить конфигурацию" (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем "загрузить конфигурацию" (не объединение)

вот пример работоспособности этого приема

DROP TABLE [dbo].[Config]

5) делаем "загрузить конфигурацию" (не объединение) из cf

после этого проверяем, проблема уходит.

P.S. Если у Вас есть возможность поделиться своим опытом, то давайте расширим данный материал.

Специальные предложения

Недавно возникла эта проблема
симтомы
1. Любое действие записи вызывает данную ошибку.
2. Не грузятся обмены
3. Невозможно запустить проверку БД и выгрузку
4. Невозможно открыть конфигуратор из-за блокировки информационной базы

Собственно никаких блокировок БД не было, проверялось и в консоли сервера приложений 1с и в консоли SQL сервера
Лечение.
1. делаем бэкап (на всякий пожарный, можно и не делать у кого смешанная модель бэкапа позволяющая восстановить базу на состояние часа назад к примеру )
2. сносим базу с сервера приложений(не трогая БД на SQL сервере)
и заводим её заново (можно наверно и перезагрузить сервер приложений 8.1,
но у меня на нем крутится более 20 баз, которые работали вполне адекватно)
итого починка занимает не более 5 минут(без бэкапа)

хотя вполне возможно у меня был частный случай. но есть у меня подозрение что гребет именно сервер приложений и сама БД тут совершенно ни причем

спасибо, интересный пример
но если не запускалась проверка, то неплохобы было увидеть текст ошибки (собрать можно технологическим), тогда причина станет очевидней (3) ПОТРЯСАЮЩЕ! А статью вы пробывали читать или ваша рекомендация отличается от приведенных рекомендаций в статье? :) ИЛИ ВЫ ПОТВЕРЖДАЕТЕ ПРАВИЛЬНОСТЬ МЕТОДА? :) подтверждаю :) опытным путем было получено, что ошибочка вылетает
при некорректном закрытии программы пользователем (во время заполнения книги продаж в типовой бухне, например ) "Ну надоело ждать".
тока все таки лучшее перегрузить, чем сносить, если есть возможность. Был еще такой глюк с такой же ошибкой в итоге, один из пользователей ставил отбор по одному из сотрудников и вылетали все. пытались повторить на других машинах и другими пользователями, хрена. дальше все продолжают успешно работать, кроме как Невозможно запустить проверку БД и выгрузку. перегружаемси, индекируемси - те же грабли. У нас не выгружались ни cf ни dt. Оказалось, что после некорректного заверешения сервера предприятия остался висеть процесс rphost. Выяснилось это только через неделю (когда увидели что их больше чем надо :)))). Судя по всему старый процесс блокировал запись в таблице config Были такие грабли, поставил сервер 2008 с сиквел 2008, 3-й месяц все в норме У меня всегда лечится перезапуском Сервера 1С. Интересно в новой платформе 8.1.13.37 не решили эту проблему?!
что-то там колдуют с контролем двоичных данных в реквизитах на размер, надеемся на 14 релиз

sel ect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

Он позволит узнать максимальные длины хранимых в них данных. Не рекомендуется хранить данные длиннее 100 - 200Mb.

Ошибка :"Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005"

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

Решение в моем случае:
Виндовс по-умолчанию 2Гб берет себе, а 2 отдает нам. SQL почти всю остальную память поедал (в настройках стоит 2Gb) и оставлял для всех остальных только 128Мб физ. памяти(как и положено SQL- он не должен забирать ВСЁ, должен 128 оставить). Ошибка 1С начала проявляться после перехода на релиз 1.2.21.1. Да, действительно, в релизе 1.2.19.1 в файле dbo.Config не было записей больше 120Мб. А вот после обновления на 1.2.21.1 такая запись (примерно 135мб )появляется. При снятии с поддержки запись исчезает сама, и ничего удалять не приходится. При постановке на поддержку -снова появляется. Я так понял, что это и есть конфигурация поставщика.
Если SQL оставляет всего 128, а надо целых 135, то вывод- надо дать рабочим процессам живую физическую память. Moжно урезать SQL. А можно винды. Установив в boot.ini ключ /3GB я тем самым отдал виндам 1Gb, а всему остальному 3Gb, а не 2/2 как по умолчанию. После перезагрузки - все ОК.
Буду рад, если эти рекомендации помогут кому-нибудь еще :-)

(14) да, в отношении Config, пункты 1 и 2 как раз и позволяют бороться с размером в 1.2.21.1. Спасибо что подтвердили верность инструкции. описанная проблема полностью описывает траблы с сифилисом который сейчас твориться у меня с базой (бекапы собственные не создаются) попробую данные здесь рекомендации. Вопрос - а если отключить поддержку, то как ее вернуть? =) как не странно помогло (проверил на демо базе =))) Возникла ошибка "Сеанс работы завершен администратором". Установив в boot.ini ключ /3GB ошибка устранилась. Огромное спасибо за полезную информацию. (21) artur.antipin, аналогичная проблема. Я думаю вряд ли поможет, если 32 Gb на сервере, SQL использует 30, 1Gb погоды не сделает а можно конкретнее пожалуйста где именно в файле boot.ini установить данный ключ /3GB ?

Недавно у клиентов была такая проблема, просто отпала база с указанной ошибкой. MS SQL 2000 показывал базу не в состоянии Suspend, а в состоянии Offline. Понятно что наивный расчет на Online базы не оправдался и я устроил допрос.

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

После перезагрузки никто не смог войти, т.к. был Offline режим файлы базы скопировать тоже не удавалось, без меня делать детач боялись. Но так как мне ничего не оставалось я нажал детач. Сервер не много подумал и отключил базу но в списке баз отключенная база осталась не отобража имени, просто пустая строка, перезапуск сервера открылся с(!) подключенной живой базой. Но была проблема, беглый осмотр основных мест показал, что полностью упали итоги регистра Заказы покупателей( изб блокировки были связаны скорее всего с этим) в итоге пришлось их пересчитывать 2,5 часа не долго, но обычно за месяц итоги считались минут 15, значит точно упали.
КонецИстории )

з.ы. причин установить не удалось

Целый день бьюсь с этой проблемой. Пришлось потанцевать с бубном. УПП 1.2.27 Платформа 15. sql 2005. Ошибка решилась соблюдением следующей последовательности действий.
1) удаляю записи больше 120 мб в sql.
2) Снимаю базу с поддержки
3)Объединяю с типовой cf 1.2.27 без галок (одновременно ставлю на поддержку) 1.2.27 предварительно протестирована и исправлена (не знаю важно ли это, но было именно так) Возникла аналогичная проблема "Соединение с сервером баз данных разорвано администратором Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005" при выгрузке конфигурации из БП 1.6.24.7 на 1С 8.2, сервер SQL 2000. Вопрос решился добавлением рабочего процесса в консоли «Серверы 1С:Предприятия 8.2». Попробуйте. :) Тоже возникла проблема с основной конфигурацией в файловом варианте. Как посоветуете drop-нуть ConfigSave?

Ошибка: Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: [DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation.
HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0

1C 8.1.14 + MS SQl 2005 + Терминальник (на 3х серверах)

Ошибка возникает при любых действиях пользователя - хаотично ((( причин установить не удалось

(27) как ваша ошибка коррелирует с указанной в статье "Неопознанная ошибка"?
У вас же проблема с большей вероятностью в включенном файрволе. (28) файрволов/антивирусов нет на сервере + Ошибка возникла без каких либо изменений в системе через год после експлуатации. (27) Vet_ne, Не подскажете как проблема решилась, у меня тоже HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0
бодаюсь пока безрезультатно.

вот выдержка из этой статьи (хоть и для 2000, но принцип тотже):

Устранение неполадок с установкой подключений
Большинство подобных неполадок в SQL Server 2000 возникает из-за проблем с протоколом TCP/IP или проверкой подлинности Windows либо сочетанием проблем обоих типов.

Внимание! Перед тем как приниматься за устранение неполадок с установкой подключений в SQL Server 2000, убедитесь, что на компьютере с SQL Server запущена служба MSSQLServer.

ping <Server Name>

Запишите возвращенный IP-адрес.
4. Из командной строки выполните следующую команду (где IP address — это IP-адрес, выписанный при выполнении действия 3):

ping –a <IP address>

Убедитесь, что команда возвращает правильное имя сервера. Если же одна из указанных выше команд завершается сбоем, возвращает неправильное значение или истекает время ожидания для ее выполнения, значит, неправильно работает просмотр DNS или существует иная проблема, связанная с функционированием сети или маршрутизацией. Чтобы просмотреть текущие параметры DNS, запустите из командной строки следующую команду:

Чтобы устранить эту проблему, добавьте запись для сервера в файл %systemroot%\system32\drivers\etc\hosts на клиентском компьютере. Кроме того, обойти проблему можно путем установки подключения к серверу с помощью сетевой библиотеки именованных каналов.

Примечание. Необходимо включить хотя бы протокол TCP/IP и именованные каналы.
3. Откройте вкладку Псевдоним и проверьте псевдонимы, настроенные для экземпляра SQL Server.
4. Убедитесь, что в свойствах псевдонимов правильно настроены имя сервера (IP-адрес) и протокол.
Можно создать новый псевдоним для тестирования подключения по имени сервера, IP-адресу или другому протоколу.

Примечание. В более ранних версиях компонентов доступа к данным Майкрософт (MDAC) интерфейс программы сетевого клиента отличается. Таким образом, если вы не видите описанных в этой статье элементов интерфейса, установите на клиентском компьютере более новую версию компонентов MDAC.

Следует отметить, что ошибки, содержащие именно код 80004005, встречаются постоянно. У них есть особая классификация, которую при желании можно найти в соответствующей литературе.

Сопутствующая проблема и методы её решения

С ситуацией, описанной ранее, тесно связана ещё одна, происходящая параллельно. Выглядит она так: 10007066.

Выглядит она таким образом:

Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005.

Когда происходит ошибка 1с hresult clr 80004005, программа завершает свою работу в аварийном режиме.

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

С помощью средств MS SQL Server Query Analizer нужно найти в табличке несколько колонок image и сделать для каждой следующий запрос

select top 10 DATALENGTH(_Fld4044 from _InfoReg4038 order by DATALENGTH(_Fld4044) desc

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

Ошибка выделения памяти hresult 80004005 (на английском это out of memory for query result 1с) может происходить вследствие различных причин, имеющей общую черту. Для системы 1С это, прежде всего, недостаток оперативной памяти. Если говорить точнее, речь идёт о некорректном применении возможностей памяти, поэтому для решения задачи лучше использовать несколько косвенных алгоритмов.

Необходимо сделать рестарт (перезапуск) сервера. Таким образом памяти, которая доступна для работы, временно станет больше. Также есть возможность воспользоваться сервером в 64 разряда, содержащем приложения.

Исходя из опыта, ошибка СУБД hresult 80004005 чаще определяется двумя факторами:

данные хранятся в хранилище значений (реквизите);
в таблице конфигураций содержатся двоичные данные объёмом более 120 мегабайт.

Когда советы от сотрудников 1С не приносят результата (ошибка 1с hresult 80004005 остаётся), попробуйте воспользоваться другой пошаговой инструкцией:

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

воспользоваться инструментами sql и сделать бэкап;
снять базу с поддержки;
выгрузить cf.

Есть ещё один способ, с помощью которого неопознанная ошибка субд hresult 80004005 может быть исправлена. Нужно открыть конфигуратор и снять конфигурацию, не сохраняя её. Далее, сохранив, нужно поместить её в отдельный файл без сохранения её изменённого вида.

Выполните в SQL операцию, предназначенную для конкретной базы:

DELETE FROM dbo.Config WHERE DataSize > 125829120

После выполнения этой команды проведите загрузку сохранённой конфигурации.

Что касается радикальных шагов, используемых в особо трудных ситуациях, иногда помогает такая схема:

Читайте также: