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

oshibka-formata-potoka-postgres-000.pngОшибка формата потока — одна из самых неприятных ошибок в работе 1С и вызывает панический ужас у многих администраторов и пользователей данной учетной системы. Ее появление обычно говорит о серьезных повреждениях базы данных и, чаще всего, наиболее верным решением будет восстановить базу из резервной копии. В случаях, когда это нежелательно или невозможно придется заняться восстановлением базы, но большинство инструкций в сети рассматривают данный вопрос только на примере MS SQL Server, а PostgreSQL если и касаются, то очень вскользь. Поэтому в данной статье мы постараемся исправить данный пробел.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Начнем с того, что именно обозначает эта ошибка. Разработчики немногословны, никаких подробностей сообщение об ошибке не содержит:

oshibka-formata-potoka-postgres-001.png

Столь же скупа и информация для технической поддержки:

oshibka-formata-potoka-postgres-002.pngОбычно это вызывает у пользователей и неподготовленных администраторов тихую панику, особенно если под рукой нет актуальной резервной копии. А судорожные попытки восстановления базы, обычно без понимания смысла выполняемых действий приводят как правило к ее полному разрушению.

К возникновению данной ошибки приводит повреждение основной конфигурации информационной базы. Реже — кеша конфигурации информационной базы, в последнем случае устранить ошибку можно путем очистки кеша, для этого можете воспользоваться нашей утилитой 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.

oshibka-formata-potoka-postgres-003.pngВыяснив имя необходимой базы данных выгрузим ее дамп командой:

#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 часов практики и доступ навсегда.

image

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

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: Ошибка формата потока'
Не загружается dt-шник. Ошибка формата потока ☑ 0

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-файла. Все вылетают с такой ошибкой.

В чем может быть проблема? Почистить кэш не предлагать))

1

sikuda

27.09.19

15:37

2

anchar007

27.09.19

15:39

(1) забыл сказать, что маленькие по размеру базы разворачиваются без проблем

3

rphosts

27.09.19

15:40

а точно версия у того что в ДТ = 1С 8.3.13.1513 ?

4

Провинциальный 1сник

27.09.19

15:41

Вы что, в файловую базу пытаетесь 110 гигов загрузить?

5

ДенисЧ

27.09.19

15:42

(4) » стоит postgresql 9.6 и сервер 1С 8.3.13.1513 х64″

6

anchar007

27.09.19

15:43

(3) точно. DT был сделан с базы под платформой 1513 и разворачивается тоже на 1513, только на другом компе

7

spiller26

27.09.19

15:43

(0) Файл подкачки смотри на сервере

8

spiller26

27.09.19

15:44

(0) 8.3.13.1513 глючный релиз

9

shuhard

27.09.19

15:45

(0) ТиИ в источнике выгрузки  сделан ?

4-ре файла выгружены 4 раза из одной и той же базы ?

10

anchar007

27.09.19

15:46

(7) NAME TYPE    SIZE USED PRIO

    none virtual   6G   0B    0

Как понять сколько нужно?

11

anchar007

27.09.19

15:47

(8) ещё пока качаю новую платформу

12

anchar007

27.09.19

15:48

(9) ТиИ не делал в источнике, надо чтобы все вышли часов на 8, а это проблематично.

Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается

13

DeeK

27.09.19

15:49

аминь

14

s_newbi

27.09.19

15:50

Если в базе есть ошибки, то она не загрузится из dt’ника

Все кто делает резервные копии — dt’никами сильно рискуют остаться без базы.

15

dezss

27.09.19

15:50

А почему делаешь через DT, а не через средства SQL?

17

Dmitry1c

27.09.19

15:53

(0) а кто бекапы 100гиговой базы в дт решил делать?

18

s_newbi

27.09.19

15:54

(15) а как средствами SQL получить 1CD?

19

anchar007

27.09.19

15:55

ок, попробую через pgadmin сделаю копию

20

piter3

27.09.19

15:55

(18) то есть все-таки файловая)

21

rphosts

27.09.19

15:56

(17) нууу, может они не умеют делать бэкапы средствами постги

22

rphosts

27.09.19

15:56

(18) какое нафиг 1CD!

23

rphosts

27.09.19

15:57

(20) т.е. у ТС каша в голове

24

piter3

27.09.19

15:57

(23) тяпница,бывает)

25

Масянька

27.09.19

15:58

(13) Поддерживаю.

Бекапы делают трусы (С)

26

anchar007

27.09.19

15:59

(23) да вы че, там чел какой то про 1CD спросил, это не я. Я пока копию через pgadmin делаю))

27

rphosts

27.09.19

15:59

(26) о, точно

28

rphosts

27.09.19

16:00

+ (26)но бэкап и ресторе нужно делать скриптами а не оболочками

29

timurhv

27.09.19

16:00

(21) ну бывает скинут bak от MSSQL 2017 и как его грузить в PostgreSQL или MSSQL 2014?

30

shuhard

27.09.19

16:01

(12)[Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается]

это тебе кажется

31

Фрэнки

27.09.19

16:02

а что только я один не понимаю, зачем ему эту всю хрень нужно затащить на клиентскую машину, если ее можно и нужно развернуть как лишнюю базу на том же сервере и в нем тестить все себе интересное на сервере?

32

shuhard

27.09.19

16:03

(26)[ Я пока копию через pgadmin делаю]

т.е. смысл поста был в троллинге форума =)

33

dmpl

27.09.19

16:04

(31) Тестить? На боевом сервере? В приличных местах за это а-та-та сделают.

34

Фрэнки

27.09.19

16:04

(32) ну да. совсем зеленые о существовании пгадмина самостоятельно не догадываются.

35

Фрэнки

27.09.19

16:05

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

36

anchar007

27.09.19

16:07

(35) ну не.. вдруг че не так пойдет. Плюс лишняя нагрузка на сервер

37

shuhard

27.09.19

16:07

(35) в ресурсах

в отключенном отладчике

38

Затейник

27.09.19

16:07

Вот соседняя ветка, уверяла Переход с Микрософта на Линукс что с postgres проблем нет, особенно с бекапами.

39

Фрэнки

27.09.19

16:08

(37) да, про отладчик я не подумал.

40

Фрэнки

27.09.19

16:10

(36) я бы, пока суть да дело, а если есть готовые ДТ, то проверил бы из них загрузку в соседнюю базу на том же сервере, чтоб лобовым способом проверить, что проблемы в ДТ нету.

41

ansh15

27.09.19

17:05

(11) Новый PostgreSQL тоже не забудь скачать. Сейчас это 10.9-5.1С.

42

dmpl

27.09.19

17:32

(35) Можно случайно перепутать тестовую базу и боевую. Можно неосторожним движением уронить процесс сервера 1С:Предприятия или SQL-сервера.

43

Провинциальный 1сник

29.09.19

07:35

(39) (37) А что за отладчикофобия? Проверял специально, влияние параметра включенной отладки на сервере на производительность влияет на уровне погрешности. Конечно, когда процесс трассируется с подключенным отладчиком, это другое дело. Но повторяю, сам по себе признак разрешения отладки не мешает работе.

44

PR

29.09.19

08:33

(0) Сколько места на системном диске?

45

ink-nsk

30.09.19

06:59

1С то ломанная?

Либо она считает себя таковой. :)))))

46

hhhh

30.09.19

07:06

согласен с (44). Что на системном диске свободного места меньше чем 110 гиг

47

Смотрящий

30.09.19

07:25

(0) У тебя битый DT. Точнее битые данные в исходной базе.

1С, формируя dt-шник, выгружает в него конфу, в трех экземплярах, потом льет сырые данные. Никаких проверьк не производится. DT-ник выгрузится всегда.

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

Проще всего данные поправить в исходной базе. И перевыгрузить dt-шник.

48

anchar007

30.09.19

08:33

(47) Да, на самом деле оказался битый dt. Все 4 dt-шника, которые я пробовал загружать были сделаны скриптами. И все оказались битые. Выгрузил вручную через конфигуратор и загрузил без ошибок

49

unregistered

30.09.19

08:55

(43) >> А что за отладчикофобия?

Это тема отдельно холивара. И даже если считать, что включение отладки не влияет на производительность (ну или пренебречь этим влиянием), остаётся проблема, когда разработчик начинает отлаживать процесс в боевых базах на продуктивном rphost-е. А этим грешат 99.9% разработчиков, где включена отладка на продуктиве.

50

unregistered

30.09.19

08:56

(48) DT — не является резервной копией для клиент-серверных баз. Это аксиома. А зачем было доказывать аксиому?…

51

Фрэнки

30.09.19

09:11

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

з.ы. И зачем нужно было годами делать как бы архивы, которые никто никогда не тестил на загружаемость ?

52

Фрэнки

30.09.19

09:13

(49) точно! Если включил отладчик на продуктиве, то значит рано или поздно, так или иначе, но пользоваться им начнешь :-)

53

Nyoko

30.09.19

09:59

(48) Это хорошо конечно, а почему средствами SQL не сделать сразу?

54

Провинциальный 1сник

30.09.19

10:09

(52) Продуктив продуктиву рознь. В 90% случаев это допустимо. Более того, часто даже необходимо подключиться отладкой к пользовательскому сеансу, чтобы выяснить что там у него не так.

55

braslavets

30.09.19

10:46

(0) Свободное место в %temp% на сервере 1с

56

ptiz

30.09.19

11:01

Я однажды sql profiler на рабочей базе включил и забыл закрыть. Полдня не могли понять, почему всё медленнее вдвое стало :)

57

anchar007

30.09.19

12:17

(53) Для этого надо отдельную тему создавать. Из SQL база никак не хотела разворачиваться. Я выгружал бэкап рабочей базы через pgadmin, создавал новую базу в pgadmin на тестовом сервере, восстанавливал данные из бэкапа в эту новую базу, и через какое-то время pgadmin писал ошибку, что не удалось загрузить данные и большой список ошибок. Пробовал через pgadmin сделать копию 100% рабочей базы на том же тестовом сервере и восстановить её в другую базу на этом же сервере — те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип). Долго разбирался с кодировками и прочей хренью на линуксе, но всё было ок, русские локали работали и пустая база создавалась с русской кодировкой. Решил обновить postgresql с 9.6 на 10, но хрен там… У версии debian, которая установлена на серваке какие-то проблемы с новым 10-ым postgresql из-за библиотеки libssl.so

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

58

Джо-джо

30.09.19

12:52

(5) нахуа тогда dt-шник?

59

Провинциальный 1сник

30.09.19

13:13

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

60

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 — что-то пошло не так… Возможно антивирус вернул старую версию файла (Каспер такое любит) или что-то еще.

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

 Пример изменений в Hosts

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

Этот варинт подойдет тольео если причиной ошибки является IPv6.

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

  1. Нажмите Win+R, напишите regedit и нажмите Enter. Откроется редактор реестра.
  2. Если появиться запрос на разрешение действий, нажмите в  диалоговом окне Контроль учетных записей пользователей кнопку Продолжить.
  3. Найдите и выберите следующий подраздел реестра:

    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpip6Parameters

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

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

IPv6 OFF

Таким образом Вы отключите протокол 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

Понравилась статья? Поделить с друзьями:
  • Postgresql ошибка отношение уже существует
  • Postgresql declare ошибка синтаксиса
  • Postgresql ошибка ошибочный литерал массива
  • Postgresql 42p01 ошибка отношение не существует
  • Postgresql ошибка нехватка памяти