Ошибка при выполнении файловой операции v8srvr://.... Бухгалтерия 3.0

На кокой платформе появилась ошибка?

У меня такая проблема, не могу решить уже около двух недель. Платформа 8,3,15,1830х86, не могу обновить нетиповую БП3,0 с версии 3,0,74,76 на версию 3,0,75,58. Клиент-серверная БД, SQL 2014.
Есть узлы РИБ, используем свой план обмена, нетиповой "Полный". После сравнения\объединения типового обновления, принимаем изменения и происходит останавка на Регистре Версии Объектов таблица регистрации изменений (max доходила до записей 80401000). Выпадает сообщение
"Ошибка при выполнении файловой операции 'v8srvr://*сервер*/**наименованиебазы*/Params/DBNames'
по причине:
Ошибка при выполнении файловой операции '*сервер*/*наименованиебазы*/params'"

Пробовала на тестовой базе выгрузку/загрузку DT, также пробовала увеличение пакетов (Network packet Size) до 16388. Не помогает.
Пыталась поставить ниже версию 3,0,75,37, тоже самое и та же ошибка.
Сейчас пробую для узлов в БД, которые либо помечены на удаление, либо не используемые в текущем плане обмена, удалить из регистра сведений версии объектов (с ними,надеюсь и удаляться данные таблицы NG_ регистраций изменений) записи. Может это сработает.
На данный момент вышла еще версия поставщика 3_0_75_93, тоже попробую поставить.
Если кто-то сталкивался именно с такой проблемой и ее преодолел, напишите, пожалуйста. Время уходит, бухгалтерия очень злится), самооценка падает...

Залезла в SQL, нашла таблицу Регистра сведений Версии объектов (у нас dbo._InfoRg18640). Эта таблица даже не имеет таблицы dbo._InfoRg18640NG. Возник вопрос: а что тогда реструктуризирует 1С при обновлении, какие записи? В панели состояния написано" реструктуризация РегистрСведений.ВерсииОбъектов таблица регистрации изменений : 80401000. Помогите, плиз

Аналогичная ситуация на той же платформе (8.3.15.1830) пытаюсь обновить БСО. Появилась, как раз после повышения платформы. Среди попробованного для решения этой проблемы, только чистка кеша привела к тому, что смог обновиться на один релиз из 3-х необходимых, после этого опять вываливается с ошибкой. Причем ранее на той же платформе обновляя ЗУП (5 релизов) дважды сталкивался с этой ошибкой, но там после перезапуска обновления оно завершалось нормально.

мне чистка кэша не помогает(

Такая же проблема, только я перевожу БП 2.0 на БП 3.0. летом пробовала переводить все вышло без сучка и задоринки только тогда на платформе 8.3.13.1644 было. а к новому году пришлось обновить релиз 2.0 и на него можно было накатить обновление, которое работает на более поздних платформах. поставила 8.3.15.1830. уже вторую неделю бьюсь с ошибками. последняя ошибка v8srvr://*сервер*/**наименованиебазы*/Params/DBNames. есть предложение найти удаляемый объект https://forum.infostart.ru/forum33/topic214013/

Помог последний пост из https://forum.mista.ru/topic.php?id=732233, выгрузка и загрузка в файловую базу тоже решает проблему. Хотя, судя по третьему посту, не всем это помогает, но размер сетевого пакета выставил, как рекомендовано было.

Получилось))) выгрузила базу и загрузила ее снова. все таблицы сели на место. ошибка пропала

Скажите еще, пожалуйста момент, когда вы выгружаете и загружаете базу: выполнили объединение с обновлением и до применения обновления выгрузили, потом загрузили базу и запускаете 1С для принятия обновления? Так?

Попробовал увеличение пакетов, не помогло. Кроме того с аналогичной проблемой столкнулся на платформе (8.3.14.1976).

В моей ситуации решение оказалось таким: ступор при обновлении возникал на реструктуризации регистра сведений Версии объектов таблицы регистрации изменений. Написала обработку для поиска имени таблицы в структуре базы 1С (_InfoRgChngR18659). У нас сейчас план обмена, который не использует Регистр сведений Версии объекта. Когда-то до меня прошлым программистом использовался "Полный" план обмена, с того момента эта таблица с данными так и осталась. Поскольку терять нечего, данные уже не нужны, в SQL воспользовалась запросом с текстом (truncate table "_InfoRgChngR18659"), очистила полностью таблицу и в базе Главного узла и во всех остальных Периферийных базах. И обновление пошло! Вот такое решение проблемы оказалось у меня.

Тестирование и исправление помогает

Такая ошибка на платформе сама 8.3.17.1549 вылечилась при повторном запуске Обновление ИБ. Но последствия были. Ошибка в Расширении: Модули &ИзменениеИКонтроль(...) стали неверно сообщать о соответствии с Основной конфигурацией.
Я знаю, что они(аналоги текстов Основной для &ИзменениеИКонтроль) хранятся в свойствах расширения, а не напрямую ссылаются с Основной. Поэтому я попробовал пересоздать одну процедуру &ИзменениеИКонтроль(...). И сразу все модули перестали давать ошибку в расширении "Проверку возможности применения".

Была подобная ошибка. Помогла очистка кэша сеансовых данных на сервере 1С.

А мне помогло выгрузка базы с клиент-серверного варианта, загрузка в файловую, обновление на файловой, и снова выгрузка загрузка уже обновленной базы.

Рассказываю как я поступил. Вдруг пригодится.
Возникла задача обновить БП 2.0 на БП 3.0. Последние релизы на текущий момент.
База SQL. Файловая не вариант, т.к. большая.

При классическом обновлении и попытке применить изменения, спустя 3-4 часа реструктуризации падала с этой ошибкой:
'v8srvr://*сервер*/**наименованиебазы*/Params/DBNames'
После падения в конфигуратор не зайти, не доходит до авторизации с ошибкой типа "Пользователь ИБ не определен" или как то так.
Она фиксится в SQL скриптом типа:
"SEL ECT Status FR OM SchemaStorage WHERE SchemaID = 0
UPD ATE SchemaStorage SET Status = 100"
нужна последняя строка. Первая просто проверка какой статус. Нам нужен 100.

Выгрузка в DT и загрузка не помогла.

Чтобы заново длительную эпопею обновления (объединения) не проходить, делал так:
Полное тестирование и исправление дважды, во всяком случае у меня.
Первое ТиИ завершается ошибкой, вообще какая то таблица в БД отсутствует.
Второе ТиИ уже проходит.

После ТиИ пробная попытка применить изменения также увенчалась ошибкой: "v8srvr://*сервер*/**наименованиебазы*/Params/DBNames".
Снова делал ".... SE T Status = 100".

Теперь снова выгрузка/загрузка DT в туже базу и после этого изменения применились.


Таким образом вкратце: иногда возможен вариант решения путем выгрузка/загрузки DT в ту же ИБ. Если не помогает, то с тестированием и исправлением перед выгрузкой DT.

Отключите все расширения, может помочь

Данная ошибка есть в баг-листе 1с и лечится переходом на 17 платформу.

Платформа 8.3.18.1563 и УПП весом 600 ГБ. Выгрузка в DT не вариант.
Полное ТиИ не делаем, много битых ссылок.
Ошибка возникла при реструктуризации, но база работает.

Проблему решила выгрузка-загрузка в/из .dt файла. Для большой базы, конечно, это не вариант.

ЗУП. Обновлял серверную базу, вышла эта ошибка. Зашел по рдп на сервер, прописал в 1С базу, зашел в конфигуратор. Там успешно через F7 обновил конфигурацию БД

Вариант со снятием с поддержки и возвратом обратно на поддержку (при сравнении со стандартной конфигой предлагает встать на поддержку) помог.

При постоянной реструктуризации регистра (который и не затрагивался в работе) помогло Фоновое обновление конфигурации, с проставленными "На сервере" и "Динамическое обновление".

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

Такая же ошибка при ИсправленииТестировании клиент-серверной базе на самом сервере. Сняла галку в Тестировщике - Реструкторизация Расширений и все пошло.

Возникла подобная ошибка в БП 3.0.128.15 (SQL) при ТИИ на этапе реструктуризации.
Делал:
1. очистка пользовательского кэша
2. выгрузка-загрузка dt
3. отключение всех расширений.
Ничего из перечисленного не помогло. Но база работает.

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

Кто то пробовал переустановить sql? Помогает? Или это слишком радикально?