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

Попробуй у клиентов и на сервере поставить патч к MDAC 2.8 support.microsoft.com/kb... »»,
у клиентов установлен тоже только TCP/IP?

их админам может пригодится http://support.microsoft.com/kb/827422/ru

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

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

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

Проверка параметров DNS
Служба Domain Name System (DNS) используется для разрешения IP-адреса в имя экземпляра SQL Server. В случае неправильного разрешения имени экземпляр SQL Server остается недоступен и появляется одно или несколько из приведенных ниже сообщений об ошибках.
SQL Server does not exist or access denied
General Network Error
Cannot Generate SSPI Context
Убедиться в том, что имя сервера разрешается правильно, можно, опросив сервер по его имени и IP-адресу с помощью команды ping. Для этого выполните следующие действия.
1. Нажмите кнопку Пуск и выберите пункт Выполнить.
2. В диалоговом окне Запуск программы введите в поле Открыть команду cmd и нажмите кнопку OК.
3. Из командной строки выполните следующую команду:

ping

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

ping –a

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

Дополнительные сведения о команде ipconfig см. в следующей статье базы знаний Майкрософт:
223413 http://support.microsoft.com/kb/223413/ Параметры, использующиеся со средством Ipconfig.exe в Windows 2000

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

Проверка включенных протоколов и псевдонимов
Проблемы с установкой подключения могут возникать, если неправильно настроен псевдоним на клиентском компьютере. Для просмотра псевдонимов служит программа сетевого клиента. Выполните следующие действия.
1. Запустите программу сетевого клиента. Если на компьютере, где запущено клиентское приложение, установлены клиентские средства SQL Server, то для запуска программы сетевого клиента необходимо выполнить следующие действия.
a. Нажмите кнопку Пуск и выберите пункт Программы.
b. В группе Microsoft SQL Server выберите пункт Программа сетевого клиента.
Если клиентские средства SQL Server на клиентском компьютере не установлены, то для запуска программы сетевого клиента необходимо выполнить следующие действия.
a. Нажмите кнопку Пуск и выберите пункт Выполнить.
b. В диалоговом окне Запуск программы введите в поле Открыть команду cliconfg и нажмите кнопку OК.
2. В диалоговом окне Программа сетевого клиента SQL Server откройте вкладку Общие и включите нужные протоколы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взято с http://www.forum.mista.ru/topic.php?id=465608

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

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

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

Установлен сервер 1C x64 (32битный тоже пробовал)

Все работает до перезагрузки. После перезагрузки при попытке подключения к базе в SQL или открытии кластера в консоли 1С получаем отлуп с такими картинками:

При подключении к серверу 1С из консоли получаем:

Ошибка соединения с сервером 1С:Предприятия 8.2:
Ошибка на сервере или соединение разорвано администратором
Ошибка формата потока

При запуске SQL базы получаем ошибку:

Ошибка при выполнении операции с информационной базой.
Ошибка на сервере или соединение разорвано администратором.
Ошибка формата потока

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

1. Остановка службы сервера 1С:Предприятия 8.2

2. Удаление процессов rmngr.exe rphost.exe (сам вылетает при завершении rmngr.exe ).

3. Очистка каталога C:\Program Files\1cv82\srvinfo\reg_1541\snccntx (у 32 битного сервера C:\Program Files (x86)\1cv82\srvinfo\reg_1541\snccntx)

4. Запуск службы сервера 1С:Предприятия 8.2

Однако, в процессе работы с SQLной конфой, можно было неожиданно поймать аварийное закрытие 1Ски с последующим получением этих же ошибок.

Были протестированы:

1. различные релизы, различные серверы,

2. различные пользователи: Система, Администратор, USR1CV82.

3. принудительное выставление полных прав этим пользователям на каталоги C:\Program Files\1cv82\ (у 32 битного сервера C:\Program Files (x86)\1cv82\) с наследованием на дочерние объекты.

4. десятки перезагрузок и многое другое.

Однако причина оказалась куда более неожиданной!

Разыменование в Windows 7 (Server 2008, 2008R2, вероятно и 2012)

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

Выполнить это просто:

1. Запустите командную строку (Win+R, наберите cmd и нажмите ОК)

2. В командной строке наберите команду "Ping" пробел и имя вашего компьютера. Именно имя, а не его IP адрес. Нажмите Enter.

3. Если система начала пинговать себя через адрес вида fabc:de12:3456:7890:ABCD:EF98:7654:3210, или другой отличный от Вашего IP адрес

Добро пожаловать в частный клуб багофичи разыменования по версии Windows 7.

Основа проблемы кроется в том, что 1С сервер не может по имени определить себя.

А вот, отображение Вашего IP в виде IPv6 - одна из самых частых причин возникновения этой ошибки.

Еще одной из причин может быть периодическое подключение к другой сети (допустим ВПНу) когда создается новый интерфейс и Винда опять же начинает разыменовывать себя "неправильно".

Ниже я опишу два решения для обхода этой "особенности".

Предварительно хочу предупредить:

Все действия с Вашим компьютером Вы производите на свой страх и риск.

Вариант №1 Добавить в Hosts свой ПК и его IP

1. Нужно найти файлик hosts в папке C:\Windows\System32\drivers\etc Если в этой папке Вы не видите файлик Hosts, значит он просто скрыт. Тогда можно нажать клавишу ALT и, в появившемся меню, выбрать "Сервис"-"Параметры папок"-"Вид" и снять там галочку "Скрывать защищенные системные файлы". Можно еще установить переключатель "Показывать скрытые файлы, папки, диски", тогда вообще все будет видно. (После манипуляций с Hosts, рекомендую вернуть галочку на ее прежнее место, что бы случайно чего не зацепить в будущем)

2. Открыть этот файлик в Notepad (блокнот) и в конец дописать строку вида 192.168.0.1 Server (IPадрес ИмяПК). Сохранить и закрыть файлик.

3. Попробовать заново пропинговать свой ПК через имя. Если Вы снова не видите нужно IP - что-то пошло не так... Возможно антивирус вернул старую версию файла (Каспер такое любит) или что-то еще.

В общем нужно добиться правильного адреса при пинге через имя.

Вариант №2 Отключить полностью протокол IPv6 (http://support.microsoft.com/kb/929852)

Стараясь быть впереди планеты всей, Windows 7, мало того что ставит IPv6 сразу ко всем интерфейсам, так она еще и ставит его в качестве дефолтного при разыменовании. Однако на сегодняшний день этот протокол мало кто использует, а следовательно его можно/нужно отключить. Помните, что снятие галочки с протокола IPv6 в интерфейсе сетевой карты ничего не даст!

Нажмите Win+R, напишите regedit и нажмите Enter. Откроется редактор реестра.
Если появиться запрос на разрешение действий, нажмите в диалоговом окне Контроль учетных записей пользователей кнопку Продолжить .
Найдите и выберите следующий подраздел реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
Дважды щелкните пункт DisabledComponents для изменения параметра DisabledComponents .
Если параметр DisabledComponents отсутствует, его необходимо создать. Для этого:
1. Находясь на ветке Parameters, в меню Правка выберите пункт Создать , а затем — Параметр DWORD (32 бита) .
2. Введите DisabledComponents и нажмите клавишу ВВОД.
3. Дважды щелкните пункт DisabledComponents .
4. Введите значение ffffffff , а затем нажмите кнопку ОК .
5. Перегрузить компьютер.

Выглядеть должно так:

Таким образом Вы отключите протокол IPv6 полностью и Винда не будет использовать его IP вдрес для разименования.

ВАЖНО!!!

Обязательно пропингуйте свой ПК через имя и убедитесь, что пинги идут на правильный IP адрес. Не всегда, с первого раза, удается отключить IPv6 (то имя параметра не совсем правильное, то значение...)

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

Я думаю каждый хоть раз, но сталкивался с ошибкой 1С Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Неопознанная ошибка HRESULT=80004005

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

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

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

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

Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С – это не достаточно оперативной памяти . А еще точнее неэффектиное использование ресурсов памяти . Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.

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

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

Взято с http://www.forum.mista.ru/topic.php?id=465608

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

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)

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

У Вас есть свое решение!? оставьте его в комментариях)