Ошибка при выполнении файловой операции во время обновления

Форум Администрирование Обновление конфигураций (UpdateCF)

Конфигурации 1cv8 1С:Управление нашей фирмой 1.6 Платформа 1С v8.3 1С:Франчайзи, автоматизация бизнеса

1. user901186 28.03.19 12:33 Сейчас в теме

Пытаюсь обновить конфигурацию нетиповую УНФ сравнением-объединением из файла на платформе 8.3.14.1565. Ключевые релизы не пропущены.

Выходит ошибка (скрин 23) "Ошибка при выполнении файловой операции 'имясервера/имябазы/params' в момент обновления конфигурации базы данных.

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

Файл-серверный вариант.

При попытке обновить эту конфигурацию на платформе 8.3.13.1644 выходит другая ошибка: "Ошибка обращения к серверу 1С:Предприятия. по причине: Сеанс работы завершен администратором. по причине: Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 11.0: Unspecified error HRESULT=80004005," (скрин 30).

Прикрепленные файлы:

По теме из базы знаний

Найденные решения

8. user901186 01.04.19 13:19 Сейчас в теме

Когда руки уже опускались, попробовала объединять не все объекты метаданных, а по частям. Начала с регистров сведения, накопления, продолжила справочниками, документами и т.д. Делала все на копии чисто для выявлении ошибки, поэтому применяла обновления на конфигурацию БД. Иногда выходила та же ошибка файловой операции, значит ошибка была в выбранных объектах для текущей итерации. В итоге, она нашлась!!! Реквизит "Обрабатывается" в перечислениях "СтатусыОбработкиТТНВходящейЕГАИС", при том, что егаис у нас вообще не используется. Этот реквизит с обновлением удалялся. Даже без сравнения-объединения конфигурация не давала удалить его, очень долго шла реструктуризация и снова выпадала ошибка файловой операции. Без пометки на изменения этого реквизита база успешно обновилась.

Решение скорее не про частную ошибку, а про алгоритм поиска этой ошибки в совсем неожиданном месте.

Уже после обновления еще раз провели тестирование, и замудренно таки удалили этот злосчастный реквизит.

Ответить

Остальные ответы

Подписаться на ответы Инфостарт бот

Свернуть все

3. Vitaly1C8 28.03.19 13:39 Сейчас в теме

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

4. user901186 28.03.19 13:48 Сейчас в теме

(3) выгружена была на 8.3.13.1644, а обновлялась на обеих - и 8.3.13.1644, и 8.3.14.1565

5. Vitaly1C8 28.03.19 14:07 Сейчас в теме

(4) для начала попробуйте снова выгрузить и объединить сравнением ; если не помогает:
выгрузите конфигурацию конечной базы, в исходной базе запустите объединение - посмотрите какие объекты изменились; Возможно этот список наведет Вас на мысль - что не так ?!

6. user901186 28.03.19 14:27 Сейчас в теме

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

9. Papilion 15.01.20 02:32 Сейчас в теме

(3) Спасибо на наводку. Развернул новую платформу на разработческом сервер, взял бэкап базы с рабочего и при сохранении обновленной базы получил такую же ошибку. Просто запустил базу в режиме пользователя и закрыл, после этого обновления успешно сохранились.

2. Fe9_min 50 28.03.19 13:28 Сейчас в теме

смотрю, с бубно уже танцевали, могу предложить - поднять копию в файловом виде (обновить и обратно загрузить .dt) и гарантировать отсутствие "ошибка обращения к серверу")))

7. user901186 28.03.19 14:56 Сейчас в теме

(2) База объемная, при загрузки dt выходит следующая ошибка

Прикрепленные файлы:

8. user901186 01.04.19 13:19 Сейчас в теме

Ответить

10. jokercmex 25.01.20 13:08 Сейчас в теме

Такая фигня может происходить и из за лишней индексации. Проверьте все объекты , где поменялась индексация и может удастся найти вредителя

11. KAPACEB.AA 466 11.04.20 10:09 Сейчас в теме

(10)
Спасибо!
В моем случае действительно проблема была в отключенной у одного из реквизитов индексации.
Включил индексацию - обновление прошло успешно.

12. gragden 55 06.10.20 06:15 Сейчас в теме

Проблему решил с этой ошибкой:
при первом обновлении заметил что место на с диске свободного 2Гб - думал из-за этого ошибка была, почистил до 10Гб - ошибка вышла и второй раз и третий
затем начал проверять почему так мало свободного места, нашел папку SQL где хранятся файлы TEMPDB - из них было три файла размер которых превышал 17Гб, то есть 3 по 17 ГБ
перенес файлы на D диск по инструкции https://its.1c.ru/db/metod8dev/content/2377/hdoc - перед переносом не забудьте отключить сервисы 1с
перезагрузился - удалил с с диска старые temp файлы - запустил обновление, стояло долго и все завершилось успешно

13. пользователь 15.10.20 06:47

Сообщение было скрыто модератором.

...

14. zildar 1 12.11.20 11:59 Сейчас в теме

Возможно, установлен слишком маленький интервал перезапуска в настройках кластера. За время жизни процесс не успевает обновить конфигурацию

16. Serj1C 483 23.01.23 18:07 Сейчас в теме

(14) Да, так и было, спасибо за наводку. У меня конфигуратор падал ровно через 20 минут при такой настройке.
А автору вопроса, видимо удалось разбить обновление на этапы, чтобы вписаться в выставленные у них настройки кластера

Прикрепленные файлы:

15. DennyPhilord 65 16.02.21 13:43 Сейчас в теме

Также помогло обновление на более свежую платформу, в нашем случае 8.3.18.1289

Оставьте свое сообщение

E-mail: