1С 8.1: Неопознанная ошибка HRESULT=80004005 или почему не выгружаются базы данных в dt

На ИТС часто даются описания кодов ошибок, но они не всегда исчерпывающие. В этой статье мы будем пытаться продолжать "исчерпывать" 🙂

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

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

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

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

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

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

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

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

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

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

http://users.v8.1c.ru/ErrCS_8_1_12_101.aspx

Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С — это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений. По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.

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

В 8.1.11 появился переключатель «запрет на фоновые задания» в
момент создания базы.

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

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

Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти http://www.gilev.ru/1c/memleak, то через некоторое время после рестарта пролема может вернуться.

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

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

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

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

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

http://partners.v8.1c.ru/forum/thread.jsp?id=543293

можно попробывать и более радикальный шаг здесь:
удаляем (в менежмент консоли) в базе данных таблицу «config»

DROP TABLE [dbo].[Config]

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

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

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

76 Comments

A380 15.01.2009 at 09:09

Недавно возникла эта проблема

симтомы

1. Любое действие записи вызывает данную ошибку.

2. Не грузятся обмены

3. Невозможно запустить проверку БД и выгрузку

4. Невозможно открыть конфигуратор из-за блокировки информационной базы

Собственно никаких блокировок БД не было, проверялось и в консоли сервера приложений 1с и в консоли SQL сервера

Лечение.

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

2. сносим базу с сервера приложений(не трогая БД на SQL сервере)

и заводим её заново (можно наверно и перезагрузить сервер приложений 8.1,

но у меня на нем крутится более 20 баз, которые работали вполне адекватно)

итого починка занимает не более 5 минут(без бэкапа)

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

Reply ↓
Gilev.Vyacheslav 15.01.2009 at 11:32

спасибо, интересный пример

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

Reply ↓
sherekhan 16.01.2009 at 09:47

проблема решается перезагрузкой sql b 1c серверов

Reply ↓
Gilev.Vyacheslav 16.01.2009 at 15:51

(3) ПОТРЯСАЮЩЕ! А статью вы пробывали читать или ваша рекомендация отличается от приведенных рекомендаций в статье? 🙂 ИЛИ ВЫ ПОТВЕРЖДАЕТЕ ПРАВИЛЬНОСТЬ МЕТОДА? 🙂

Reply ↓
sherekhan 16.01.2009 at 18:04

подтверждаю 🙂 опытным путем было получено, что ошибочка вылетает

при некорректном закрытии программы пользователем (во время заполнения книги продаж в типовой бухне, например ) «Ну надоело ждать».

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

Reply ↓
Gilev.Vyacheslav 16.01.2009 at 19:49

(5) давайте пожалуйста не будем мешать все комбинации с кодом HRESULT=80004005, чувствую придеться отдельно писать еще

Глюк с отбором достаточно известен — это проблема нулевых дат, падает MS SQL Server 2005, обещали исправить в SP3, но действительно ли исправили можете как раз самостоятельно (обновить до SP3)

на партнерском форуме сам подымал этот вопрос — все «валят» на мелкомягких (мол проблема на стороне субд :))) )

Reply ↓
anderson 20.01.2009 at 08:47

У нас не выгружались ни cf ни dt. Оказалось, что после некорректного заверешения сервера предприятия остался висеть процесс rphost. Выяснилось это только через неделю (когда увидели что их больше чем надо :)))). Судя по всему старый процесс блокировал запись в таблице config

Reply ↓
sledr 21.01.2009 at 05:17

Были такие грабли, поставил сервер 2008 с сиквел 2008, 3-й месяц все в норме

Reply ↓
newgyn 23.01.2009 at 14:43

У меня всегда лечится перезапуском Сервера 1С. Интересно в новой платформе 8.1.13.37 не решили эту проблему?!

Reply ↓
Gilev.Vyacheslav 23.01.2009 at 16:42

что-то там колдуют с контролем двоичных данных в реквизитах на размер, надеемся на 14 релиз

Reply ↓
Gilev.Vyacheslav 23.01.2009 at 17:49

некоторые ошибки можно кстати понять с помощью ТЖ http://infostart.ru/blogs/929

Reply ↓
Gilev.Vyacheslav 06.04.2009 at 16:19

Практический пример применения данного приема хочу предложить на моем авторском курсе http://www.gilev.ru/1c/mssql/kurs.htm

Можно заранее задать вопросы по вашему предприятию, которые мы разберем на курсе.

Reply ↓
Gilev.Vyacheslav 29.04.2009 at 20:06

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

sel ect top 10 DATALENGTH(_Fld4044)

from _InfoReg4038

order by DATALENGTH(_Fld4044) desc

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

Reply ↓
subor 15.05.2009 at 18:54

Ошибка :»Соединение с сервером баз данных разорвано администратором

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 как по умолчанию. После перезагрузки — все ОК.

Буду рад, если эти рекомендации помогут кому-нибудь еще 🙂

Reply ↓
Gilev.Vyacheslav 15.05.2009 at 19:54

(14) да, в отношении Config, пункты 1 и 2 как раз и позволяют бороться с размером в 1.2.21.1. Спасибо что подтвердили верность инструкции.

Reply ↓
evgeny.shabalin@mondibp.com 19.05.2009 at 16:28

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

Reply ↓
Gilev.Vyacheslav 19.05.2009 at 16:53

(16) практика показывает, что эта проблема решается с вероятностью 99%

если что, пишите на почту gilev_slava собачка mail.ru

попробую помочь (бесплатно)

Reply ↓
Gilev.Vyacheslav 19.05.2009 at 16:56

да, все забывал написать, более свежий вариант (тут почему то статьи не обновляются) лежит http://www.gilev.ru/1c/memleak/memorymore.htm

Reply ↓
evgeny.shabalin@mondibp.com 19.05.2009 at 17:00

Вопрос — а если отключить поддержку, то как ее вернуть? =) как не странно помогло (проверил на демо базе =)))

Reply ↓
Gilev.Vyacheslav 19.05.2009 at 18:34

при загрузке cf предложит поставить

Reply ↓
artur_antipin 26.10.2009 at 19:32

Возникла ошибка «Сеанс работы завершен администратором». Установив в boot.ini ключ /3GB ошибка устранилась. Огромное спасибо за полезную информацию.

Reply ↓
ПодводныйТ 18.01.2010 at 15:57

а можно конкретнее пожалуйста где именно в файле boot.ini установить данный ключ /3GB ?

Reply ↓
TheReal0 10.02.2010 at 17:51

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

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

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

КонецИстории )

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

Reply ↓
kravius12 24.03.2010 at 14:22

Целый день бьюсь с этой проблемой. Пришлось потанцевать с бубном. УПП 1.2.27 Платформа 15. sql 2005. Ошибка решилась соблюдением следующей последовательности действий.

1) удаляю записи больше 120 мб в sql.

2) Снимаю базу с поддержки

3)Объединяю с типовой cf 1.2.27 без галок (одновременно ставлю на поддержку) 1.2.27 предварительно протестирована и исправлена (не знаю важно ли это, но было именно так)

Reply ↓
const77 13.04.2010 at 12:31

Возникла аналогичная проблема «Соединение с сервером баз данных разорвано администратором Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка

HRESULT=80004005″ при выгрузке конфигурации из БП 1.6.24.7 на 1С 8.2, сервер SQL 2000. Вопрос решился добавлением рабочего процесса в консоли «Серверы 1С:Предприятия 8.2». Попробуйте. 🙂

Reply ↓
SiAl 28.04.2010 at 13:38

Тоже возникла проблема с основной конфигурацией в файловом варианте. Как посоветуете drop-нуть ConfigSave?

Reply ↓
Vet_ne 05.05.2010 at 15:10

Ошибка: Сеанс работы завершен администратором.

по причине:

Соединение с сервером баз данных разорвано администратором

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х серверах)

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

Reply ↓
Gilev.Vyacheslav 05.05.2010 at 17:31

(27) как ваша ошибка коррелирует с указанной в статье «Неопознанная ошибка»?

У вас же проблема с большей вероятностью в включенном файрволе.

Reply ↓
Vet_ne 07.05.2010 at 02:04

(28) файрволов/антивирусов нет на сервере + Ошибка возникла без каких либо изменений в системе через год после експлуатации.

Reply ↓
Gilev.Vyacheslav 07.05.2010 at 08:56

Reply ↓
Vet_ne 07.05.2010 at 11:02

(30) Спасибо, попробую

Reply ↓
yurii123 29.06.2010 at 13:47

Как поступить в случае 3-х обединенных конфигураций? Одна из записей в Config больше 120Мб.

Сервера win2008R2x64 6Гб ОЗУ SQL 2005 3Гб выделено под SQL и win2008Stx32 4Гб ОЗУ. Та же ошибка :ошибка СУБД: Interface 0c733a7c-2a1c-11ce-ade5-00aa0044773d.

Перезагрузки и перезапуски служб не помогают. Снимал с потдержки все три конфы, так и не выгружается база.

Reply ↓
Gilev.Vyacheslav 29.06.2010 at 14:21

(32) юзать х64 софт и мозг не выносить

Reply ↓
yurii123 29.06.2010 at 14:24

(33) Спасибо, давно это напрашивалось

Reply ↓
dinn 05.07.2010 at 10:24

const77 пишет:

решился добавлением рабочего процесса в консоли «Серверы 1С:Предприятия 8.2». Попробуйте.

Спасибо, помогло!!!

Reply ↓
mil4a 30.07.2010 at 18:36

а что делать, если даже конфигурацию в файл не сохраняет?:(

Reply ↓
Gilev.Vyacheslav 30.07.2010 at 19:23

(36) x64

Reply ↓
MaxS 21.09.2010 at 07:19

Уже снятая с поддержки и давно работающая база на SQL 2005 вдруг перестала бэкапиться средствами 1С. Ругается на единственного пользователя самого себя в базе, мол он мешает. Сохранить конфигурацию тоже не даёт.

Сделал DELETE FROM dbo.Config WHERE DataSize > 125829120

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

Reply ↓
Gilev.Vyacheslav 21.09.2010 at 10:25

(38) думаю пригодиться всем

Reply ↓
mista2009 28.01.2011 at 12:14

Не выгружалось cf, dt и т.д. с ошибкой

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

HRESULT=80004005

Помог запрос

DELETE FROM dbo.Config WHERE DataSize > 125829120

Такое ощущение что удаляется какой-то мусор, т.к. после удаления все конфигурации и данные на месте.

Reply ↓
serega_sun 29.04.2011 at 05:14

Столкнулся с аналогичной проблемой. Есть запись около 140 Мб. База не выгружается в *.dt — при этом ругается на уже запущенный сеанс конфигуратора, как будто пытается установить второе соединение. Конфигурация не выгружается. Все на 32 битной системе. SQL-2005. Конфигурация доработанная комплексная автоматизация. Платформа 8.2.13.218.

Как решил — Создал типовую базу, снял с поддержки, сравнением/объединением внес все изменения, которые были. Максимальная запись при этом появилась 101 Мб. Многовато, но в пределах. Загрузил полностью конфигурацию на рабочую базу. Начала выгружаться.

Теперь вопрос: использование 64 битного ПО позволит забыть об этой проблеме? (ОЗУ 12 Гб). Или записи более 120Мб на нем тоже не выгружаются? Сомнения навевает то, что конфигуратор все равно 32 битное приложение и если памяти не хватает ему а не серверу, то проблема не решится.

З.Ы. На тестовой базе попробовал сделать удаление большой записи из БД как в (40). Запустил конфигуратор и приложение — все вроде работает, тестирование/исправление говорит, что все ОК, но при попытке сравнить конфигурацию поставщика с конфигурацией БД конфигуратор закрылся без всяких сообщений.

Так что работает, но не все.

Reply ↓
Moll 20.12.2011 at 18:08

Проверка конфигурации помогла, благодарим за инфу

Reply ↓
sashacd 25.12.2011 at 19:09

Еще одна проблема, которая решается с помощью данной статьи.

После обновления УПП с 1.2.х на 1.3.х, не работает создание резервной копии средствами СУБД PostgreSQL, а именно работа pg_dump завершаеся с ошибкой —

«pg_dump: Команда была: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;».

Для выполнения запросов иcпользуем PgAdminIII

1) “SELECT FROM Config WHERE DataSize > 125829120” — увидеть, что такая запись есть;

2) “DELETE FROM Config WHERE DataSize > 125829120” ;

А если учесть тот факт, что создание архивной копии pg_dump необходимо выполнять и во время работы пользователей в базе — то статья очень пригодилась.

Reply ↓
Spartan 29.12.2011 at 11:04

А у нас вообще возникла веселая ситуация после конвертации базы на 8.2.

При обновлении сконвертирванной базы выдавалось сообщение «Нарушена целостность структуры конфигурации». Опытным путем выяснил, что при конвертации структура конфигурации поставщика не была преобразована в формат 8.2, а осталась по прежнему в формате 8.1. Причем засада была в том, что конвертировали мы БП 2.0.21.2, а такого релиза под 8.2 не было. Победил следующим образом: выгрузил конфигурацию поставщика в файл, загрузил в пустую базу с использованием платформы 8.1, конвертнул базу эту базу на 8.2, выгрузил получившуюся конфигурацию. В рабочей базе снял конфигурацию с поддержки и объединил с моим новым файлом с постановкой на поддержку, выполнил проверку логической целостности конфигурации (исправились ошибки). Один раз база обновилась нормально. Далее при обновлении на следующий релиз начала выдаваться пресловутая ошибка «Соединение с сервером баз данных разорвано администратором Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка HRESULT=80004005». Долго игрался на копии базы со снятием и постановкой на поддержку (в db.Config больших записей не было), но база обновлялась после этих манипуляций только на один релиз, далее — опять ошибка. В итоге выгрузил базу в dt, загрузил локально в файловом варианте, и накатил последовательно все релизы — никаких ошибок не возникло, в конце опять выгрузка в dt из локальной копии и загрузка в рабочую клиент-серверную версию.

Reply ↓
ssega 23.01.2012 at 21:17

(27) Vet_ne, Не подскажете как проблема решилась, у меня тоже HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0

бодаюсь пока безрезультатно….

Reply ↓
maratimus 25.01.2012 at 12:23

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

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

Reply ↓
maratimus 25.01.2012 at 12:29

памяти у меня много 24 гб,

хенон 4 ядерный,

3 процесса крутятся на 1с сервере 8.2.14.533,

ВиндосСервер2003, Скуль 2005.

Reply ↓
maratimus 25.01.2012 at 12:57

Поробовал в тестовой сделать, сначало для просмотра (вывело 1 файл размером 165мб)

SELECT [FileName]

,[Creation]

,[Modified]

,[Attributes]

,[DataSize]

,[BinaryData]

FROM [_ka_typical].[dbo].[Config]

where [DataSize] > 125829120,

А потом DELETE FROM [_ka_typical].[dbo].[Config]

where [DataSize] > 125829120

————————————————

Теперь при сравнении основной конфигурации с конфигурацией поставщика выдает дамп …

Reply ↓
1vasia1 02.02.2012 at 13:10

Большой респект за (delete from dbo.Config where DataSize > 125829120)

Решилась проблема с выгрузкой *.cf и *.dt после очередного обновления допиленой конфы

Ошибка разрыва соединения устранена!

Reply ↓
1vasia1 02.02.2012 at 13:11

Респект Гилёву!

Reply ↓
VarvarV 12.04.2012 at 11:38

Реально помогает перевод операционной системы сервера 1С с 32 на 64 разряда:

http://forum.infostart.ru/forum24/topic41158/message647724/#message647724

Reply ↓
den_vladimir 20.04.2012 at 09:19

Большое спасибо за статью! Помогло!

Reply ↓
Famza 21.06.2012 at 15:51

Сервер Вин 2003, Скул 2005, УПП 1.3.27.1 — не выгружалась конфа в файл с ошибкой HRESULT=80004005 и тд.

Спасибо, помог в boot.ini ключ /3GB.

Есть запись большого размера — тут помог запрос SELECT * FROM dbo.Config WHERE DataSize > 125829120 — удалять не стал, выгрузка прошла успешно.

Примечательно, что только одна из баз УПП выбивала ошибку — именно та у которой была включена возможность редактирования конфигурации.

Также выбивает ошибку при обновлении на локальной машине — Вин ХР, СП3, 2 гига ОЗУ — начиная где-то с УПП 1.3.23.1. Но уже с другой ошибкой — «Всплывающее окно приложения: 1cv8.exe — Ошибка приложения : Исключение unknown software exception (0x40000015) в приложении по адресу 0x7857bea4.» — УПП 1.3.26.1

Reply ↓
bolush 25.06.2012 at 14:58

Метод Перезагрузка Сервера Рулит:)))

Reply ↓
Famza 25.06.2012 at 15:46

(54) bolush, к сожалению даже многократный ребут не помогал

Reply ↓
energosf_vl 03.07.2012 at 07:30

Доброго времени суток.

Сеанс работы завершен администратором.

по причине:

Соединение с сервером баз данных разорвано администратором

Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка

HRESULT=80004005,

Бухгалтерия предприятия, редакция 2.0 (2.0.34.13)

Microsoft SQL Server 2005

Windows Server 2003 R2

Снял с поддержки конфу и проблема решилась.

Но конфигурация сильно доработанная, как ее теперь поставить на поддержку не изменяя основную конфигурацию?

Reply ↓
GeorgeU 24.07.2012 at 14:26

4 дня боролся с этой хренью. Не выгружалась и не загружалась база из/в dt из скуля 2005 , система WinServer2003 r2, 8 Гигов оперативы. УПП 1.3.27.4 нетиповая возможность редактирования с поддержкой поставщика., платформа 8.2.294,

Нашарил в интернете разные решения. В том числе искал и здесь. Итак вкратце что путем многочисленных проб выяснил следующее:

1.Типовая УПП выгружается/обновляется без проблем. Пустая dt около 255М. Нетиповая резко увеличивает размер до 430 М. Как я понял, при снятии «замочков» сразу разделяется Основная конфигурация (разработчика) и конфигурация поставщика. Отсюда и возникновение проблем.

2.Реально при переводе в скуль в таблице Config при нетиповой есть запись более 125 МБ. SELECT * FROM dbo.Config WHERE DataSize > 125829120

У меня например одна такая запись. Если её бахнуть средствами скуля DELETE FROM dbo.Config WHERE DataSize > 125829120 тогда выгрузка загрузка идут, но появляются проблемы с обновлением. Хоть и есть конфа поставщика, хоть и на первом этапе находит нужное обновление- упрямо потом появляется окошко «файл не содержит нужных обновленией». Пипец какой то!

3. Пункт 2 на самом деле это частный случай банального ПОЛНОГО снятия конфигурации с поддержки конфигурации поставщика. Как я понимаю, очищается таблица Config но точно не знаю.Конфигурация поставщика исчезает, но если пере снятием с поддержки сохранить cf где есть поддержка, и потом загрузить в базу (скульную или файловую) то проблема решается. Конфа становится измененной, на поддержке поставщика. Важно только чтобы cf была той которая нужна!

4. Сохранение скульной упп конечно надо делать средствами скуля.

5.Что реально помогло- booi.ini /3GB

Reply ↓
nii45 03.08.2012 at 16:21

Добрый день!

Спасибо за статью и за коментарии!

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

помогло только

SELECT * FROM имябазы.dbo.Config WHERE DataSize > 125829120

DELETE FROM имябазы.dbo.Config WHERE DataSize > 125829120

У меня вопрос, как понять что за запись я удалил?

Запись ada14b12-452d-4f85-9d71-99554e8fc6c0.895e9bb0-c332-4fbd-954c-b64cae7d1998

Reply ↓
denklu 23.08.2012 at 13:49

у меня то же такая проблема, с поддержки снял, все сохранил, а как теперь обратно на поддержку поставить?

Reply ↓
shuhard 23.08.2012 at 15:44

(59)

а как теперь обратно на поддержку поставить

сравнить-объединить с cf полной поставки и ответить Да на вопрос о постановке на поддержку, далее снять все галки

Reply ↓
jump0 26.09.2012 at 11:51

Такая же проблема случилась, пока не разобрался.

Reply ↓
FeliceYa 19.11.2012 at 13:27

У меня тоже была данная проблема. Возникала при попытках выгрузить конфигурацию, или при попытке обновления конфигурации базы данных.

Помогло изменение настройки SQL сервера: Максимальный размер памяти сервера. Изначально было установлено около !!!! 200ТБт (как Вам такое количесво ОЗУ отведённое одной программе?) , и это при установленных на сервере 18ГБт. Уменьшение данного значения до 12,5ГБт (с перезапуском служб серверов SQL и 1С) помогло. Данная ошибка больше не возникает!

Reply ↓
kadet 06.06.2013 at 18:47

Мне помогло вот это:

1. На SQL переводим базу в однопользовательский режим.

ALTER DATABASE «base» SET SINGLE_USER with rollback immediate

2. Тестируем базу с исправлением ошибок.

use master

EXEC sp_dboption «base», ‘single user’, ‘TRUE’

DBCC CHECKDB («base»,REPAIR_ALLOW_DATA_LOSS)

3. Переводим базу обратно в многопользовательский режим.

ALTER DATABASE «base» SET MULTI_USER

4. Для верности: перезагружаем сервер 1С и сервер SQL.

Reply ↓
svetlana-a-s 11.09.2013 at 10:14

Столкнулась с такой проблемой при загрузке инфобазы на сервер SQL — решение оказалось до банальности простым: проверила и перезаписала настройки базы в администрировании серверов 1с Предприятия

Reply ↓
poyson 21.11.2013 at 10:34

Спасибо, помогло снятие с поддержки…

Reply ↓
borrman 14.01.2014 at 12:15

Добрый день, коллеги!

Платформа 8.2.19.76

SQL Server 2012 (11.0.2100)

Взял базы от клиента в виде резервной копии sql-сервера (у клиента стоит sql 2008. Проблема у них та же самая).

Восстановил из резервной копии.

При выгрузке — ошибка

http://content.screencast.com/users/borrman/folders/Snagit/media/f1b22f6b-68ab-481e-b6aa-2c468f7c6124/01.10.2014-18.07.png

Регламентных заданий нет

Других сеансов тоже нет — проверял.

На скрине сеанс 232 — это сеанс конфигуратора (смотрел в управлении сервером)

Что делал:

— перезапускал службы серверов (и 1С, и SQL)

— перезапускал вообще весь сервер

— при попытке снять конфигурацию с поддержки — ошибка:

http://content.screencast.com/users/borrman/folders/Snagit/media/254777f2-6e70-4362-93af-7871971a207c/01.10.2014-18.19.png

Снял техн. журнал (прикреплен). В общем ошибка при выгрузке та же.

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

Reply ↓
borrman 14.01.2014 at 13:49

Вопрос снят

помог способ в (63)

Но тут вопрос sp_dboption в 2012 нет. Его нужно добавлять? Вообще для чего эта процедура?

Reply ↓
kadet 14.01.2014 at 14:49

(67) borrman, Честно говоря, сам не знаю для чего эта процедура. Способ нарыл на бескрайних просторах инета.

Reply ↓
quazar-ed 02.10.2014 at 13:28

полезная информация, спасибо!

Reply ↓
PchelkaR 17.12.2014 at 10:31

У нас была такая ошибка и никакие описанные действия не помогали. Проблема была решена тем, что сервер 1С запустили не из под доменного пользователя, а из под локального админа.

Reply ↓
kazann 22.01.2015 at 15:51

Сегодня возникла такая ситуация первый раз за несколько лет использования. Думал уже перепробовать все озвученные способы, но помогла перезагрузка сервера 1С. Спасибо!

Reply ↓
igor_1c 04.02.2015 at 17:02

(21) artur.antipin, аналогичная проблема. Я думаю вряд ли поможет, если 32 Gb на сервере, SQL использует 30, 1Gb погоды не сделает

Reply ↓
mtv:) 10.01.2016 at 20:37

Бился с такой же ошибкой. Помогла установка в boot.ini ключа /3GB.

Большое спасибо за полезную информацию.

Reply ↓
casuallf 11.01.2016 at 16:42

Появилась и у меня такая ошибка, а именно:

Неопознанная ошибка HRESULT=80004005

Возникала при выгрузке КФ или ДТ

База серверная УНФ 1.4 на поддержке, сильно доработанная

Вылечил просто:

1) Захватил корень хранилища

2) Запустил Тестирование и исправление со всеми галками

3) Поместил в хранилище корень

После этого проблема исчезла.

Reply ↓
olbu 14.10.2016 at 08:54

Здравствуйте!

У меня периодически валится фоновое задание на этой ошибке:

Соединение с сервером баз данных разорвано администратором

Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка

HRESULT=80004005,

Перезапуск вручную — фоновое задание срабатывает. Платформа 1с 8.2.19.102. УПП не типовая, снятая с поддержки.

Никто не сталкивался? Может подскажете как диагностировать и решить?

Reply ↓
ligsht 28.03.2019 at 10:25
Платформа 8.3.10.2252

При попытке выгрузить DT:

Ошибка обращения к серверу 1С:Предприятия.

по причине:

Сеанс работы завершен администратором.

по причине:

Соединение с сервером баз данных разорвано администратором

Microsoft SQL Server Native Client 10.0: Unspecified error

HRESULT=80004005,

запрос:
```
DELETE FROM dbo.Config WHERE DataSize > 125829120
```
показывал что запись около 250 мб. В других рабочих базах есть записи и по 500мб и работает без проблем.

Проверил размер всех таблиц в базе:
```
Use Enterprise_Base

select  t.name as TableName, Min(t.create_date) as CreateDate, ds.name as FileGroupName, SUM(u.total_pages) * 8 / 1024 as SizeMB
from sys.tables as t
inner join sys.partitions as p on t.object_id = p.object_id
inner join sys.allocation_units as u on p.partition_id = u.container_id
inner join sys.data_spaces as ds on u.data_space_id = ds.data_space_id
group by t.name, ds.name
order by SizeMB desc
```
Показать
Одна из таблиц была больше 10 гб. Выяснилось что таблица была регистра сведений коллизии при обмене. Полностью почистили таблицу и все заработало.

Reply ↓

1С 8.1: Неопознанная ошибка HRESULT=80004005 или почему не выгружаются базы данных в dt

Related Posts

76 Comments

Leave a Comment Отменить ответ