Встановлено сервер 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 відсутня, його необхідно створити. Для цього:- Перебуваючи на гілці Parameters,у меню Виправлення виберіть пункт створити, а потім - Параметр DWORD (32 біти).
- Введіть DisabledComponents і натисніть клавішу ENTER.
- Двічі клацніть пункт DisabledComponents.
- Введіть значення ffffffff, а потім натисніть кнопку ОК.
- Перевантажити комп'ютер.
Виглядати має так:
Таким чином Ви вимкніть протокол IPv6 повністю і Винда не використовуватиме його IP вдрес для разіменованія.
ВАЖЛИВО !!!
Обов'язково пропінгуйте свій ПК через ім'я і переконайтеся, що пінг йдуть на правильний IP адреса. Не завжди, з першого разу, вдається відключити IPv6 (то ім'я параметра не зовсім правильне, то значення ...)
Хочу нагадати, що обидва рішення не є панацеєю, і не насправді дозволяють обійти помилку, а не усунути її причину.
Я думаю кожен хоч раз, але стикався з помилкою 1С З'єднання з сервером баз даних розірвано адміністратором Microsoft SQL Server Native Client 10.0: Невизначена помилка HRESULT \u003d 80004005
Ось деякі способи, які допоможуть вирішити дану проблему:
1. Перевірити конфігурацію на наявність некоректної інформації (сміття). Для цього слід виконати команду "Перевірка конфігурації" з встановленим прапорцем "Перевірка логічної цілісності конфігурації". При виявленні проблем буде видано повідомлення. Некоректна інформація при цьому буде видалена автоматично, однак слід забезпечити доступність для зміни кореневого об'єкта конфігурації (напимер, при роботі зі сховищем його слід захопити).
2. Якщо Ваша конфігурація знаходиться на підтримці, слід так само перевірити конфігурацію постачальника. Для цього в налаштуванні підтримки слід зберегти конфігурацію постачальника в cf файл, завантажити його в нову базу і виконати описану в пункті 1 процедуру. У разі, якщо було отримано повідомлення про виправлення, значить конфігурація постачальника містить некоректну інформацію. В цьому випадку слід зняти Вашу конфігурацію з підтримки і заново поставити шляхом об'єднання зі свіжим релізом установки постачальника. В даний час все релізи випускаються 1С проходять перевірку і випускаються без даної проблеми.
3. Також з цією ситуацією перетинається наступна ситуація:
10007066 Запис даних, що містять колонки типу ХраніліщеЗначенія
проблема:
При використанні СУБД MS SQL SERVER під час запису об'єкта бази даних, що містить кілька колонок типу ХраніліщеЗначенія, дані для яких отримані з файлів, може відбуватися помилка
Помилка СУБД: Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT \u003d 80004005і аварійне завершення роботи програми.
Включивши технологічний журнал на час завантаження, можна визначити таблицю, в якій містяться такі сховища. Знайдіть засобами MS SQL Server Query Analizer в цій таблиці колонки типу image. Для кожної колонки типу image виконайте запит виду:
S_elect top 10 DATALENGTH (_Fld4044)
from _InfoReg4038
order by DATALENGTH (_Fld4044) desc
Нюанси: зверніть увагу, що "Стандартні перевірки" платформою (chdbfl, в конфігураторі) наполегливо говорять, що з базою все ОК.
Суть проблеми: важливо, що під це повідомлення про помилку можуть підпадати різні причини, але у них є загальна частина для 1С - це мало оперативної пам'яті. А ще точніше нееффектіное використання ресурсів пам'яті. Звідси непрямі методи перемогти проблему: шляхом рестарту сервера (на некотрое час ставати більше доступної пам'яті) або перейти на 64-розрядний сервер додатків.
1С: Підприємство 8.2. Ліцензія на сервер (x86-64)
З досвіду проблема пов'язана зі зберіганням даних в реквізиті сховище значень або наявністю в таблиці config довічних даних БІЛЬШЕ 120 mb.
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\u003d543293
1. Відкрити конфігратор;
2. Зняв конфігурацію з підтримки, ПРИ ЦЬОМУ конфігурації не зберігається!
3. Далі Зберегти конфігурацію в файл (без збереження зміненої конфігурації);
4. У SQL для необхідної бази виконав наступну команду:
DELETE FROM dbo.Config WHERE DataSize\u003e 125829120
5. Завантажити збережену конфігурацію назад.
Взято з http://www.forum.mista.ru/topic.php?id\u003d465608
Можна спробувати і більш радикальний крок тут:
видаляємо (в менеджмент консолі) в базі даних таблицю "config"
D_rop TABLE.
5) робимо "завантажити конфігурацію" (не об'єднання) з cf
після цього перевіряємо, проблема йде.
6) Помилка: "З'єднання з сервером баз даних розірвано адміністратором
Microsoft OLE DB Provider for SQL Server: Невизначена помилка
HRESULT \u003d 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 як за замовчуванням. Після перезавантаження - все ОК.
У Вас є своє рішення !? залиште його в коментарях)
На ІТС часто даються описи кодів помилок, але вони не завжди вичерпні. У цій статті ми будемо намагатися продовжувати «вичерпувати» 🙂
При есклуатаціі баз даних 1С ви можете сталкнуться з такою ситуацією:
Сеанс роботи завершено адміністратором.
по причині:
З'єднання з сервером баз даних розірвано адміністратором
Microsoft OLE DB Provider for SQL Server: Невизначена помилка
HRESULT \u003d 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 \u003d 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\u003d543293
1. Відкрити конфігратор;
2. Зняв конфігурацію з підтримки, ПРИ ЦЬОМУ конфігурації не зберігається!
3. Далі Зберегти конфігурацію в файл (без збереження зміненої конфігурації);
4. У SQL для необхідної бази виконав наступну команду:
DELETE FROM dbo.Config WHERE DataSize\u003e 125829120
5. Завантажити збережену конфігурацію назад.
Взято з http://www.forum.mista.ru/topic.php?id\u003d465608
можна спробувати і більш радикальний крок тут:
видаляємо (в менежмент консолі) в базі даних таблицю «config»
DROP TABLE.
5) робимо «завантажити конфігурацію» (не об'єднання) з cf
після цього перевіряємо, проблема йде.
Спробуй у клієнтів і на сервері поставити патч до 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
Can not Generate SSPI Context
Переконатися в тому, що ім'я сервера дозволяється правильно, можна, опитавши сервер по його імені і IP-адресою за допомогою команди ping. Для цього виконайте такі дії.
1. Натисніть кнопку Пуск і виберіть пункт Виконати.
2. У діалоговому вікні Запуск програми введіть в полі Відкрити команду cmd і натисніть кнопку ОК.
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 і натисніть кнопку ОК.
2. У діалоговому вікні Програма мережевого клієнта SQL Server відкрийте вкладку Загальні і включіть потрібні протоколи.
Примітка. Необхідно включити хоча б протокол TCP / IP і іменовані канали.
3. Відкрийте вкладку Ім'я користувача і перевірте псевдоніми, налаштовані для екземпляра SQL Server.
4. Переконайтеся, що у властивостях псевдонімів правильно налаштовані ім'я сервера (IP-адреса) і протокол.
Можна створити новий псевдонім для тестування підключення по імені сервера, IP-адресою або іншому протоколу.
Примітка. У більш ранніх версіях компонентів доступу до даних Майкрософт (MDAC) інтерфейс програми мережевого клієнта відрізняється. Таким чином, якщо ви не бачите описаних в цій статті елементів інтерфейсу, встановіть на клієнтському комп'ютері новішу версію компонентів MDAC.