Всем доброго вечера! Есть базы ЗУП 3.1.12.56 (самое новье) и вот по ряду причин (долго рассказывать) надо вернуться к 3.1.10.223
Копия базы 3.1.10.223 есть, но ей уже пара недель и нагружать работника повторным вводом документов очень не хочется. На одной
базе попробовал вернуться назад через загрузку конфигурации 3.1.10.233. Сделал тестирование и исправление, ошибок нет.
Есть ли какие-то подводные камни, на которые в дальнейшем можно напороться ? Или можно смело так поступать ?

Думаю не будет проблем.

но кэши лучше вычиситить

Вернул релиз обратно, вроде все работает. Точнее, не жаловались. Но вот стал сегодня обновлять на 3.1.10.253
под 8.3.13.1513 и при применении обработчиков выдает "Неверный формат хранилища данных". Кэш чистил, переносил в другой каталог, на другую машину, не помогает. Запустил обновление под 8.3.14, обновляется
без проблем. Понижал релиз под 8.3.15.  Реструктуризацию под 8.3.13 делал, выгружал, загружал, не помогает. Получается, что в базе остались следы от 8.3.15, несовместимые с 8.3.13. Как мне преобразовать это хранилище данных к 8.3.13?

(0) Я бы не стал так делать.

(4)как так ?

(4)если ты про саму тему, то уже поздно, сделал, надо выкручиваться

(6) Движение "назад" - это всегда гемор. Причем с вероятностью 80% результат будет отрицательный.
20% оставил "на чудо".

(7)я это делал впервые, потому и написал тему. Никто не отговорил. Откуда такая статистика ?

(3) выгрузка загрузка данных. база большая?

(9)Делал, не помогает. База маленькая

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

(11)что спросили , то и отвечаю. Делал выгрузку из под 8.3.14  и затем загрузку под 8.3.13. Потом обновление, и тот же результат при выполнении обработчиков
(11)если имеете в виду выгрузку загрузку XML, то столь радикальный метод пока не применял

(12) ну поставьте 8.3.14 и работайте. Вот нахрена вам 8.3.13? Бзик что ли в голову ударяет? У нее же глюк на глюке.

(13)есть причины помимо бзика.

(14) ну тогда Копия базы 3.1.10.223 есть, но ей уже пара недель и нагружать работника повторным вводом документов

(15) ну можно еще поднять копию и использовать выгрузку загрузку XML из текущей базы

(14)Можно попробовать сделать копию новой базы, накатить на неё ЦФ старой копии, затем из полученного результата выгрузкой/загрузкой документов, перетащить нужные документы и перепровести..

вангую, что можно еще раз попробовать.

CF откуда взяли, который загружали? Может надо попытаться еще раз?
Взять нулячую базу, созданную из полного дистриба. Открыть в ней конфигуратором конфиг Поставщика. Выгрузить его в файл.

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

(18) тут конфигурации не причем. Сам формат базы данных в 14 слегка поменялся. И если они уже поработали в базе без режима совместимости, то вернуться на старый формат хранения базы не получится. Поэтому на 13-й не будет работать, или будут глюки, запорют базу в итоге через пару месяцев. Там вроде есть в 1с утилиты по преобразованию базы в старый формат, может их попробовать.

(19)да, я думаю именно в этом все дело. Конфа нормальная. Типовая. Ошибок базы при тестировании и исправлении нет. Под 8.3.14 и выше все работает, под 8.3.13 нет. Под 8.3.13 не удается и заново загрузить 223 редиз, при выполнении обработчиков та же проблем с форматом хранилища. Видимо надо вернуться к исходной проблеме.
Несколько упрощая (баз не по одной, а больще):

1. Есть база 7.7 (переписанная ТИС 9.2 с блоком производства, всех устраивает, еще поживет)
2. Есть типовая ЗУП 3.1
3. Есть типовая БП 3.0 (с небольшими расширениями)

Эти базы взаимодействуют:

1. 7.7 -> БП 3.0 (OLE)
2. БП 3.0 -> 7.7 (OLE. текстовые файлы)
3. ЗУП 3.1 -> БП 3.0 (синхронизация с прямым подключением, те есть COM)

Юзеры работают в терминале. Админа сейчас практически нет, был, но не стало. Всеми подключениями к серверу, правами на все и вся, кроме 1С ведал он. Поэтому желательно исключить или минимизировать вмешательство в инфраструктуру этого хозяйства.
Так как есть синхронизация ЗУП -> БП, то мне представляется логичным, чтобы они сидели на одной платформе 8.3.x. Да и плодить платформы не хочется. Может как раз тут я и ошибаюсь. Можно ли посадить ЗУП и БП на разные платформы?
Так вот, вся проблема (тут есть еще моя тема) возникла из-за того, что начиная с 8.3.14 при вызове БП 3.0 В из 7.7 все прекрасно работает, но процесс 1сv8.exe остается в памяти. Попробовал несколько платформ, вплоть до 8.16, попробовал вместо БП 3.0 чистые базы в обычном и управляемом режиме, все бесполезно. Процесс 1сv8.exe остается в памяти. На 8.3.13 и ниже все отлично.
Плэтому и хотелось бы пока остаться на 8.3.13 (хотя может 1С очень скоро очередным обновлением БП 3.0 утащит всех за уши на очередную 8.x.y). Но пока остаться и думать как избавиться от 7.7 -> БП 3.0 (OLE). Все равно этой технологии видимо приходит кирдык. Мне совершенно непонятно, почему начиная с 8.3.14 объект
V83.Application стад вести себя по другому, может это и сознательно сделано, иначе бы уже исправили. Видимо в 8.3.14 поменяли не только формат
(19)но как поменять. Обновлятор (точнее, встроенная в него утилита 1С ) показывает 8.3.8. Другого формата вроде бы нет. Чистая база отлично обновляется под 8.3.13, то есть все дело именно в базе, чего я изначально и боялся, но я боялся что при откате испортятся какие то реквизиты, а тут засада с форматом хранилища.

Забрезжил лучик надежды. Поставил 8.3.13.1926 (последняя из серии чертовой дюжины)
1. ЗУП успешно обновляется (сейчас еще раз проверю)) )
2. 7.7 -> БП 3.0 (OLE) работает. В памяти ничего не остается.
А вообще, на мой субъективный взгляд, ситуация с платформами уже просто неприличная. Крупный разработчик не должен так себя вести. Да и одновременно 3 редакции ЗУП тоже не вполне красиво.
Проверил еще раз, 8.3.13.1926 работает. Это конечно не значит, что еще что то не вылезет, теперь страх до конца жизни ))