Перешли на 8.3.18.1208, обнаружили критический баг через неделю, хотели вернуться на 8.3.10.2667, выдает ошибку "Ошибка формата потока"
Кто-то сталкивался с подобным, может подскажете, как можно полечить?

Переходи на 8.3.12.1289, чисти кэш

(0)Кеш?

Кэш и серверный и локальный чистили

Не дает даже зарегать базу через консоль настройки кластера с аналогичной ошибкой

Находил тему на формуме, что у человека была похожая проблема, он переносил из sql конфиг файлы. Кто-то может знает какие?

Платформа 8.3.17.1823 и 8.3.17.1549 совместимость блин.

(0) А что такой разброс платформ то. База может и не работать на 10 платформе,  попробуйте на 17 версию хотябы

Пробовал на 8.3.17 такая же ошибка, работает только на 8.3.18 теперь

(8) А внутри какая версия совместимости стоит?

Пробовал разные. Изначально поставил 8.3.10, потом 8.3.17. Не помогло

Если поможете решить с меня пиво )

Ну, на крайний случай - выгрузить/загрузить или через РИБ.

(0) Да , нормально, смотри в (1)

(2) Хоть форматни виндовс, ошибка останется :)

(12) И это тоже не поможет, только обновить платформу на (1)

(1) а почему именно эта версия?

(16) Предыдущая багованная.
Так же у 1С были описаны ошибки, которые при переходе на прошлые версии приводили к плохим последствиям.

+ (16) 8.3.18.1289 ... релиз 18

После перехода на 18 понизить не получается. С 17 на 16, похоже, тоже.

(19) Наверное, специально так сделали. Чтобы все пиратские платформы медным тазом накрылись.

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

А что пишет, когда не удается перейти обратно?

Вот так вот помогает:
"Связано это с повреждением таблиц Config, ConfigSave, DBSchema, Params.
1) Отключаем пользователей из поврежденной базы данных;
2) Запускаем скрипт:
go
truncate table [dbo].[Config]
truncate table [dbo].[ConfigSave]
truncate table [dbo].[DBSchema]
truncate table [dbo].[Params]
—truncate table [dbo].[Files]
go
insert into [dbo].[Config] select * from [РабочаяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Config]
insert into [dbo].[DBSchema] select * from [РабочаяБазаИзБекапаНаЭтомЖеСервере].[dbo].[DBSchema]
insert into [dbo].[Params] select * from [РабочаяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Params]
go
3) Вычищаем кэш на компьютере, с которого будем восстанавливать таблицы.
4) Запускаем скрипт:
delete from dbo._ConfigChngR
delete from dbo._ConfigChngR_ExtProps
5) Перезапускаем агента 1С (перезапускаем сервер приложений).
6) Заходим в конфигуратор, отключаем хранилище, создаем какое-либо изменение метаданных, сохраняем конфигурацию и применяем изменения к базе данных.
7) Подключаемся к хранилищу, сохраняем изменения и применяем изменения к БД
8) Проверяем документы.
9) Работаем."

+(23) Если хранилище не использовалось и между рабочей копией и поврежденной были изменения в конфиге, то ой. Можно конечно руками править, но долго и не известно когда и где будут проблемы вылезать.

Будем сегодня пробовать, спасибо, по результатам отпишусь

+ подпишусь

(11) когда распределение приза будет?

Пока решили жить на 8.3.18 с ее глюком сворачивания окна, и пропадающими разделами. Как только им надоест, проверим и разыграем ))

(24) судя по этому комментарию мы уже в пролётё (

вероятно совместимость в ней траблы