Ошибка формата потока — одна из самых неприятных ошибок в работе 1С и вызывает панический ужас у многих администраторов и пользователей данной учетной системы. Ее появление обычно говорит о серьезных повреждениях базы данных и, чаще всего, наиболее верным решением будет восстановить базу из резервной копии. В случаях, когда это нежелательно или невозможно придется заняться восстановлением базы, но большинство инструкций в сети рассматривают данный вопрос только на примере MS SQL Server, а PostgreSQL если и касаются, то очень вскользь. Поэтому в данной статье мы постараемся исправить данный пробел.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Начнем с того, что именно обозначает эта ошибка. Разработчики немногословны, никаких подробностей сообщение об ошибке не содержит:
Столь же скупа и информация для технической поддержки:
Обычно это вызывает у пользователей и неподготовленных администраторов тихую панику, особенно если под рукой нет актуальной резервной копии. А судорожные попытки восстановления базы, обычно без понимания смысла выполняемых действий приводят как правило к ее полному разрушению.
К возникновению данной ошибки приводит повреждение основной конфигурации информационной базы. Реже — кеша конфигурации информационной базы, в последнем случае устранить ошибку можно путем очистки кеша, для этого можете воспользоваться нашей утилитой 1:Tools (кто хочет поддержать нас — может скачать ее по ссылке с Инфостарта)
1:Tools (Зеркало на Инфостарте)
MD5: 448277422B59EFA426CC51E4F3A52F53
В остальных случаях придется заниматься восстановлением непосредственно базы. В этом месте мы сразу внесем ясность и разделим сущности: информационная база 1С — это хранилище данных на уровне логики 1С:Предприятия которое описывается конфигурацией информационной базы. Т.е. именно здесь содержатся документы, справочники, регистры и т.д. и т.п., а повреждение конфигурации информационной базы делает невозможной работу с ними на этом уровне абстракции. База данных СУБД — это набор таблиц в которых хранятся как данные, так и конфигурация информационной базы 1С.
Повреждение основной конфигурации информационной базы происходит именно на уровне логики 1С:Предприятия, база данных СУБД остается работоспособной и не содержит ошибок с точки зрения СУБД. Если это не так, то мы будем иметь дело с повреждением самой базы данных СУБД, а это уже совсем иная ситуация.
В зависимости от того, какая именно часть конфигурации ИБ оказалась повреждена база может не загружаться в обычном режиме, но загружаться в Конфигуратор, либо вообще не загружаться никак. Если доступен режим конфигуратора, то можно попробовать снять базу с поддержки и загрузить в нее исправную конфигурацию из файла, в некоторых случаях это приведет к успеху, в других может потребоваться сначала выявить и удалить сбойный элемент метаданных.
Все это достаточно сложно и не всегда приносит требуемый результат, поэтому проще и надежнее заменить конфигурацию информационной базы на заведомо исправную используя инструменты СУБД, в нашем случае PostgreSQL. В зависимости от используемой ОС (Windows или Linux) некоторые аспекты работы с PostgreSQL могут отличаться и это будет оговорено отдельно, в остальных случаях указанные команды применяются вне зависимости от платформы.
Перед тем как начинать работу с PostgreSQL в Linuх последовательно повысим свои права для суперпользователя и затем войдем в систему от имени пользователя postgres:
sudo -s
su postgres
Если утилита sudo не установлена (такой вариант может быть в Debian), то:
su -
su postgres
В первом случае вам потребуется ввести пароль от текущей учетной записи, во втором — от учетной записи суперпользователя (root).
Затем обязательно сделаем копию информационной базы средствами СУБД. Получить список баз данных в кластере СУБД можно командой:
psql -l
В Windows вам потребуется ввести пароль пользователя postgres.
Выяснив имя необходимой базы данных выгрузим ее дамп командой:
#Linux
pg_dump basename > ~/basename.psql#Windows
pg_dump basename > D:\backup\basename.psql
Где basename — имя нужной базы данных. Обратите внимание, что в Windows мы можем явно задать путь выгрузки дампа, а в Linux выгружаем его в домашнюю директорию пользователя postgres, т.е. /var/lib/postgresql.
Для дальнейших действий нам потребуется развернуть на этом же сервере СУБД еще одну базу с точно такой же конфигурацией информационной базы, это может быть как старый бекап поврежденной базы, так и другая база такой же конфигурации, чистая установка или демо база. Главное, чтобы конфигурация новой базы с точностью до релиза совпадала с конфигурацией поврежденной.
После чего откроем интерактивный терминал PostgreSQL в котором будем производить все последующие действия:
psql
В Windows вы можете получить сообщение:
ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной
страницы Windows (1251).
8-битовые (русские) символы могут отображаться некорректно.
В этом случае выполните:
\! chcp 1251
Теперь подключимся к исправной базе:
\с newbasename
где newbasename — имя исправной базы данных. При этом в строке приглашения появится имя подключенной базы.
Из нее мы выгрузим таблицу config в которой находится основная конфигурация информационной базы.
#Linux
COPY config TO '/var/lib/postgresql/config_OK.txt';#Windows
COPY config TO 'D:/backup/config_OK.txt';
Обратите внимание, при указании пути для операционной системы Windows вы также должны использовать прямой, а не обратный слеш. Также служба СУБД должна иметь права на запись в целевую аудиторию, проще всего это сделать выдав полные разрешения для пользователя Все.
Переподключимся к поврежденной базе:
\с basename
На всякий случай, также сохраним содержимое таблицы config:
#Linux
COPY config TO '/var/lib/postgresql/config_ERR.txt';#Windows
COPY config TO 'D:/backup/config_ERR.txt';
После чего очистим сбойную таблицу:
DELETE FROM config;
И загрузим в нее данные из исправной информационной базы:
#Linux
COPY config FROM '/var/lib/postgresql/config_OK.txt';#Windows
COPY config FROM 'D:/backup/config_OK.txt';
Для выхода из терминала PostgreSQL введите:
\q
Если все сделано правильно, то поврежденная конфигурация информационной базы будет заменена на исправную и ее работоспособность будет восстановлена.
В некоторых случаях оказывается повреждена не основная конфигурация информационной базы, а конфигурация, открытая на редактирование в Конфигураторе. Внешне это проявляется как невозможность загрузить информационную базу в этом режиме. Для исправления этой ошибки достаточно очистить таблицу configsave:
DELETE FROM configsave;
Как видим, устранение ошибки формата потока средствами СУБД PostgreSQL достаточно несложно, однако требует некоторых навыков работы с данной СУБД. Но если вы будете внимательно и вдумчиво следовать нашей инструкции, то проблем у вас возникнуть не должно.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Проблема в создавшейся базе, я получаю ошибку при попытке подключиться конфигуратором в созданную базу.
CREATEINFOBASE "Srvr=srv;Ref=sa4;DBMS=PostgreSQL;DBSrvr=/tmp/postgresql/socket;DB=sa4;DBUID=postgres;LicDstr=Y;Locale=ru_RU;CrSQLDB=Y;SchJobDn=N;"
47:13.608000-0,EXCP,1,process=1cv8,OSThread=693,Exception=d294e384-7ea6-49c6-be96-f3a6e3de1242,Descr='LoadComponent(cfgtest):
d294e384-7ea6-49c6-be96-f3a6e3de1242: Ошибка загрузки компоненты cfgtest: '
47:14.019000-0,EXCP,2,process=1cv8,OSThread=693,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="./src/ClientFileCacheImpl.cpp(280):
9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'v8stg64://c:/1/DynamicalWorkCache': ./src/Storage64.cpp(3077)"
47:14.020002-0,EXCP,2,process=1cv8,OSThread=693,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="./src/ClientFileCacheImpl.cpp(280):
9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'v8stg64://c:/3/DynamicalWorkCache': ./src/Storage64.cpp(3077)"
47:15.737001-0,EXCP,1,process=1cv8,OSThread=693,Exception=e88a796d-7758-48a7-9ba7-781e269e9aa4,Descr='./src/ExceptionWriterUIImpl.cpp(224), shown to the user:
e88a796d-7758-48a7-9ba7-781e269e9aa4: Ошибка формата потока'
anchar007
27.09.19
✎
15:33
Пытаюсь развернуть DT рабочей базы на тестовой машине.
DT весит 9 Гб, а сама база примерно 110 Гб. База клиент-серверная, сервер на debian, стоит postgresql 9.6 и сервер 1С 8.3.13.1513 х64. Клиентская терминальная машина на Windows, на ней стоит 8.3.13.1513 х64.
Запускаю загрузку базы из DT, проходит 5 минут, база начинает весить 2,3 Гб и всё, выходит ошибка «В информационную базу загружены не все данные 1с. Ошибка формата потока»
Пробовал загрузить 4 разных DT-файла. Все вылетают с такой ошибкой.
В чем может быть проблема? Почистить кэш не предлагать))
sikuda
27.09.19
✎
15:37
anchar007
27.09.19
✎
15:39
(1) забыл сказать, что маленькие по размеру базы разворачиваются без проблем
rphosts
27.09.19
✎
15:40
а точно версия у того что в ДТ = 1С 8.3.13.1513 ?
Провинциальный 1сник
27.09.19
✎
15:41
Вы что, в файловую базу пытаетесь 110 гигов загрузить?
ДенисЧ
27.09.19
✎
15:42
(4) » стоит postgresql 9.6 и сервер 1С 8.3.13.1513 х64″
anchar007
27.09.19
✎
15:43
(3) точно. DT был сделан с базы под платформой 1513 и разворачивается тоже на 1513, только на другом компе
spiller26
27.09.19
✎
15:43
(0) Файл подкачки смотри на сервере
spiller26
27.09.19
✎
15:44
(0) 8.3.13.1513 глючный релиз
shuhard
27.09.19
✎
15:45
(0) ТиИ в источнике выгрузки сделан ?
4-ре файла выгружены 4 раза из одной и той же базы ?
anchar007
27.09.19
✎
15:46
(7) NAME TYPE SIZE USED PRIO
none virtual 6G 0B 0
Как понять сколько нужно?
anchar007
27.09.19
✎
15:47
(8) ещё пока качаю новую платформу
anchar007
27.09.19
✎
15:48
(9) ТиИ не делал в источнике, надо чтобы все вышли часов на 8, а это проблематично.
Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается
DeeK
27.09.19
✎
15:49
аминь
s_newbi
27.09.19
✎
15:50
Если в базе есть ошибки, то она не загрузится из dt’ника
Все кто делает резервные копии — dt’никами сильно рискуют остаться без базы.
dezss
27.09.19
✎
15:50
А почему делаешь через DT, а не через средства SQL?
Dmitry1c
27.09.19
✎
15:53
(0) а кто бекапы 100гиговой базы в дт решил делать?
s_newbi
27.09.19
✎
15:54
(15) а как средствами SQL получить 1CD?
anchar007
27.09.19
✎
15:55
ок, попробую через pgadmin сделаю копию
piter3
27.09.19
✎
15:55
(18) то есть все-таки файловая)
rphosts
27.09.19
✎
15:56
(17) нууу, может они не умеют делать бэкапы средствами постги
rphosts
27.09.19
✎
15:56
(18) какое нафиг 1CD!
rphosts
27.09.19
✎
15:57
(20) т.е. у ТС каша в голове
piter3
27.09.19
✎
15:57
(23) тяпница,бывает)
Масянька
27.09.19
✎
15:58
(13) Поддерживаю.
Бекапы делают трусы (С)
anchar007
27.09.19
✎
15:59
(23) да вы че, там чел какой то про 1CD спросил, это не я. Я пока копию через pgadmin делаю))
rphosts
27.09.19
✎
15:59
(26) о, точно
rphosts
27.09.19
✎
16:00
+ (26)но бэкап и ресторе нужно делать скриптами а не оболочками
timurhv
27.09.19
✎
16:00
(21) ну бывает скинут bak от MSSQL 2017 и как его грузить в PostgreSQL или MSSQL 2014?
shuhard
27.09.19
✎
16:01
(12)[Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается]
это тебе кажется
Фрэнки
27.09.19
✎
16:02
а что только я один не понимаю, зачем ему эту всю хрень нужно затащить на клиентскую машину, если ее можно и нужно развернуть как лишнюю базу на том же сервере и в нем тестить все себе интересное на сервере?
shuhard
27.09.19
✎
16:03
(26)[ Я пока копию через pgadmin делаю]
т.е. смысл поста был в троллинге форума =)
dmpl
27.09.19
✎
16:04
(31) Тестить? На боевом сервере? В приличных местах за это а-та-та сделают.
Фрэнки
27.09.19
✎
16:04
(32) ну да. совсем зеленые о существовании пгадмина самостоятельно не догадываются.
Фрэнки
27.09.19
✎
16:05
(33) а им не похрен где тестить? чего такого страшного в запуске теста на отдельной базе, ну пускай даже на том же сервере?
anchar007
27.09.19
✎
16:07
(35) ну не.. вдруг че не так пойдет. Плюс лишняя нагрузка на сервер
shuhard
27.09.19
✎
16:07
(35) в ресурсах
в отключенном отладчике
Затейник
27.09.19
✎
16:07
Вот соседняя ветка, уверяла Переход с Микрософта на Линукс что с postgres проблем нет, особенно с бекапами.
Фрэнки
27.09.19
✎
16:08
(37) да, про отладчик я не подумал.
Фрэнки
27.09.19
✎
16:10
(36) я бы, пока суть да дело, а если есть готовые ДТ, то проверил бы из них загрузку в соседнюю базу на том же сервере, чтоб лобовым способом проверить, что проблемы в ДТ нету.
ansh15
27.09.19
✎
17:05
(11) Новый PostgreSQL тоже не забудь скачать. Сейчас это 10.9-5.1С.
dmpl
27.09.19
✎
17:32
(35) Можно случайно перепутать тестовую базу и боевую. Можно неосторожним движением уронить процесс сервера 1С:Предприятия или SQL-сервера.
Провинциальный 1сник
29.09.19
✎
07:35
(39) (37) А что за отладчикофобия? Проверял специально, влияние параметра включенной отладки на сервере на производительность влияет на уровне погрешности. Конечно, когда процесс трассируется с подключенным отладчиком, это другое дело. Но повторяю, сам по себе признак разрешения отладки не мешает работе.
PR
29.09.19
✎
08:33
(0) Сколько места на системном диске?
ink-nsk
30.09.19
✎
06:59
1С то ломанная?
Либо она считает себя таковой. :)))))
hhhh
30.09.19
✎
07:06
согласен с (44). Что на системном диске свободного места меньше чем 110 гиг
Смотрящий
30.09.19
✎
07:25
(0) У тебя битый DT. Точнее битые данные в исходной базе.
1С, формируя dt-шник, выгружает в него конфу, в трех экземплярах, потом льет сырые данные. Никаких проверьк не производится. DT-ник выгрузится всегда.
Обратная ситуация при загрузке, 1с проверяет корректность загружаемых данных; и, если они битые (кривой уникид, число не влезает в разрядность, циклические ссылки и т.п.) то получаешь ошибку формата потока.
Проще всего данные поправить в исходной базе. И перевыгрузить dt-шник.
anchar007
30.09.19
✎
08:33
(47) Да, на самом деле оказался битый dt. Все 4 dt-шника, которые я пробовал загружать были сделаны скриптами. И все оказались битые. Выгрузил вручную через конфигуратор и загрузил без ошибок
unregistered
30.09.19
✎
08:55
(43) >> А что за отладчикофобия?
Это тема отдельно холивара. И даже если считать, что включение отладки не влияет на производительность (ну или пренебречь этим влиянием), остаётся проблема, когда разработчик начинает отлаживать процесс в боевых базах на продуктивном rphost-е. А этим грешат 99.9% разработчиков, где включена отладка на продуктиве.
unregistered
30.09.19
✎
08:56
(48) DT — не является резервной копией для клиент-серверных баз. Это аксиома. А зачем было доказывать аксиому?…
Фрэнки
30.09.19
✎
09:11
(50) ну как бы у него аксиома получилась двоякая — ДТ вручную Конфигуратором работает, а хз откуда взятые скрипты создавали ДТ битый.
з.ы. И зачем нужно было годами делать как бы архивы, которые никто никогда не тестил на загружаемость ?
Фрэнки
30.09.19
✎
09:13
(49) точно! Если включил отладчик на продуктиве, то значит рано или поздно, так или иначе, но пользоваться им начнешь
Nyoko
30.09.19
✎
09:59
(48) Это хорошо конечно, а почему средствами SQL не сделать сразу?
Провинциальный 1сник
30.09.19
✎
10:09
(52) Продуктив продуктиву рознь. В 90% случаев это допустимо. Более того, часто даже необходимо подключиться отладкой к пользовательскому сеансу, чтобы выяснить что там у него не так.
braslavets
30.09.19
✎
10:46
(0) Свободное место в %temp% на сервере 1с
ptiz
30.09.19
✎
11:01
Я однажды sql profiler на рабочей базе включил и забыл закрыть. Полдня не могли понять, почему всё медленнее вдвое стало
anchar007
30.09.19
✎
12:17
(53) Для этого надо отдельную тему создавать. Из SQL база никак не хотела разворачиваться. Я выгружал бэкап рабочей базы через pgadmin, создавал новую базу в pgadmin на тестовом сервере, восстанавливал данные из бэкапа в эту новую базу, и через какое-то время pgadmin писал ошибку, что не удалось загрузить данные и большой список ошибок. Пробовал через pgadmin сделать копию 100% рабочей базы на том же тестовом сервере и восстановить её в другую базу на этом же сервере — те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип). Долго разбирался с кодировками и прочей хренью на линуксе, но всё было ок, русские локали работали и пустая база создавалась с русской кодировкой. Решил обновить postgresql с 9.6 на 10, но хрен там… У версии debian, которая установлена на серваке какие-то проблемы с новым 10-ым postgresql из-за библиотеки libssl.so
Короче понял, что без админов в линукс лучше не лезть, откатил всё обратно, попробовал вручную сделать бэкап рабочей базы и развернуть его. Чудом всё получилось. Дальше буду с админами разбираться что не так с бэкапами postgresql
Джо-джо
30.09.19
✎
12:52
(5) нахуа тогда dt-шник?
Провинциальный 1сник
30.09.19
✎
13:13
(57) Что-то мне помнится, что для восстановления бэкапа постгреса надо сначала базу создать из 1с, а потом уже восстанавливать бэкап поверх существующей базы. Что-то там с определяемыми типами, которые создаются в контексте базы, и эти определения не сохраняются в бэкапе.
shuhard
30.09.19
✎
13:16
(57)[ те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип)]
дык это 100500 раз описано, да есть фичи
При подключении к серверу 1С из консоли получаем:
Ошибка соединения с сервером 1С:Предприятия 8.2:
Ошибка на сервере или соединение разорвано администратором
Ошибка формата потока
При запуске SQL базы получаем ошибку:
Ошибка при выполнении операции с информационной базой.
Ошибка на сервере или соединение разорвано администратором.
Ошибка формата потока
И так, исходные данные:
Свежеустановленная Windows 7 Professional x64, все апдейты и т.д. (проблема имеет место и на Server 2008 и на 2008R2)
Произведена установка платформы 1С 8.2 (тестировались релизы 8.2.16.368, 8.2.16.363, 8.2.15.319)
Установлен сервер 1C x64 (32битный тоже пробовал)
Все работает до перезагрузки. После перезагрузки при попытке подключения к базе в SQL или открытии кластера в консоли 1С получаем отлуп с такими картинками:
При подключении к серверу 1С из консоли получаем:
Ошибка соединения с сервером 1С:Предприятия 8.2:
Ошибка на сервере или соединение разорвано администратором
Ошибка формата потока
При запуске SQL базы получаем ошибку:
Ошибка при выполнении операции с информационной базой.
Ошибка на сервере или соединение разорвано администратором.
Ошибка формата потока
Для возможности запуска базы и подключения к кластеру из консоли помогало только:
1. Остановка службы сервера 1С:Предприятия 8.2
2. Удаление процессов rmngr.exe rphost.exe (сам вылетает при завершении rmngr.exe).
3. Очистка каталога C:Program Files1cv82srvinfo
eg_1541snccntx (у 32 битного сервера C:Program Files (x86)1cv82srvinfo
eg_1541snccntx)
4. Запуск службы сервера 1С:Предприятия 8.2
Однако, в процессе работы с SQLной конфой, можно было неожиданно поймать аварийное закрытие 1Ски с последующим получением этих же ошибок.
Были протестированы:
1. различные релизы, различные серверы,
2. различные пользователи: Система, Администратор, USR1CV82.
3. принудительное выставление полных прав этим пользователям на каталоги C:Program Files1cv82 (у 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:WindowsSystem32driversetc Если в этой папке Вы не видите файлик Hosts, значит он просто скрыт. Тогда можно нажать клавишу ALT и, в появившемся меню, выбрать «Сервис»-«Параметры папок»-«Вид» и снять там галочку «Скрывать защищенные системные файлы». Можно еще установить переключатель «Показывать скрытые файлы, папки, диски», тогда вообще все будет видно. (После манипуляций с Hosts, рекомендую вернуть галочку на ее прежнее место, что бы случайно чего не зацепить в будущем)
2. Открыть этот файлик в Notepad (блокнот) и в конец дописать строку вида 192.168.0.1 Server (IPадрес ИмяПК). Сохранить и закрыть файлик.
3. Попробовать заново пропинговать свой ПК через имя. Если Вы снова не видите нужно IP — что-то пошло не так… Возможно антивирус вернул старую версию файла (Каспер такое любит) или что-то еще.
В общем нужно добиться правильного адреса при пинге через имя.
Вариант №2 Отключить полностью протокол IPv6 (http://support.microsoft.com/kb/929852)
Этот варинт подойдет тольео если причиной ошибки является IPv6.
Стараясь быть впереди планеты всей, Windows 7, мало того что ставит IPv6 сразу ко всем интерфейсам, так она еще и ставит его в качестве дефолтного при разыменовании. Однако на сегодняшний день этот протокол мало кто использует, а следовательно его можно/нужно отключить. Помните, что снятие галочки с протокола IPv6 в интерфейсе сетевой карты ничего не даст!
- Нажмите Win+R, напишите regedit и нажмите Enter. Откроется редактор реестра.
- Если появиться запрос на разрешение действий, нажмите в диалоговом окне Контроль учетных записей пользователей кнопку Продолжить.
- Найдите и выберите следующий подраздел реестра:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpip6Parameters
- Дважды щелкните пункт DisabledComponents для изменения параметра DisabledComponents.
Если параметр DisabledComponents отсутствует, его необходимо создать. Для этого:- Находясь на ветке Parameters, в меню Правка выберите пункт Создать, а затем — Параметр DWORD (32 бита).
- Введите DisabledComponents и нажмите клавишу ВВОД.
- Дважды щелкните пункт DisabledComponents.
- Введите значение ffffffff , а затем нажмите кнопку ОК.
- Перегрузить компьютер.
Выглядеть должно так:
Таким образом Вы отключите протокол IPv6 полностью и Винда не будет использовать его IP вдрес для разименования.
ВАЖНО!!!
Обязательно пропингуйте свой ПК через имя и убедитесь, что пинги идут на правильный IP адрес. Не всегда, с первого раза, удается отключить IPv6 (то имя параметра не совсем правильное, то значение…)
Хочу напомнить, что оба решения не являются панацеей, и не самом деле позволяют обойти ошибку, а не устранить ее причину.
Ошибка «Ошибка формата потока»
Posted Ноябрь 28th, 2013 by xakep008
in
- Установка и настройка PostgreSQL
Добрый день.
Установил PostgreSQL 9.0.3-3.1 на Windows Server 2012, 1С Server 8.2.19.68.
Возникает проблема при работе с базой. При проведении документа «Ошибка формата потока».
В файловом варианте база работает исправно.
Скачал патчи для PostgreSQL с официального сайта 1С.
КАК ИХ УСТАНОВИТЬ? Файлы с расширением .patch и .src.
- Войдите или зарегистрируйтесь, чтобы добавлять комментарии
Back to top