New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Open
SminexIT opened this issue
Nov 12, 2021
· 4 comments
Assignees
Labels
bug
Something isn’t working
Синхронизация с ИБ
Механизм синхронизации с инфо-базазой, приложения (applications)
Comments
Описание ошибки
ИБ клиент-серверная (MS SQL), примерный размер 120 ГБ
При длительном обновлении ИБ (длительной реструктуризации), процесс иногда падает с ошибкой ..DBNames.
Если после этого попробовать сразу снова обновить ИБ из EDT, возникает ошибка «Запись не найдена в менеджере имен базы данных», после чего ИБ не подлежит восстановлению (по крайней мере пока способы не найдены)
(Было предположение, что это как-то связано с «удалёнными» расширениями, но удаление всех расширений в базе и тестирование и исправление расширений на логическую целостность не помогает)
Логи EDT показывают следующую информацию: Таблица Chrc29665 отсутствует в схеме базы данных (pos=100), где Chrc — планы видов характеристик (в данном случае ошибка возникла после добавления предопределенного реквизита в План Видов Характеристик)
Но при анализе таблиц БД, такую таблицу (Chrc29665) найти не удалось.
Ошибка повторялась как минимум:
- после добавления предопределенного реквизита в План Видов Характеристик
- после добавления реквизита в документ
- после изменения длины строкового реквизита в справочнике (в этом случае ошибка была: Таблица Reference28658 отсутствует в схеме базы данных (pos=1525), данная таблица в ИБ так же не найдена)
Как воспроизвести
- Добавить/Изменить любой реквизит, в любом объекте, в котором в БД содержится очень много элементов (чтобы вызвать длительную реструктуризацию),
- Кликнуть по разрабатываемому приложению — Обновить конфигурацию
- Дождаться появления ошибки ..DBNames (понятно что появляется далеко не всегда, обычно при проблемах с сетью)
- Повторно кликнуть по разрабатываемому приложению — Обновить конфигурацию
Скриншоты
Ожидаемое поведение
ошибка «Запись не найдена в менеджере имен базы данных» не возникает и ИБ не разрушается
Лог рабочей области
trace.log
[ATT35712.log](https://github.com/1C-Company/1c-edt-issues/files/7527954/ATT35712.log
bak_0.log
)
trace.bak_0.log
Версия 1С:EDT
2021.2.6
Операционаня система
Windows
Установленые плагины
Нет плагинов
Дополнительная информация
Версия платформы 8.3.20.1549
(Было предположение, что это как-то связано с «удалёнными» расширениями
У меня точно такая же проблема произошла, после удаления 5 из 6 расширений из базы. И есть BAK этой базы до удаления расширений 100% воспроизводимость, сейчас оформляю на v8@1c.ru . EDT тут ни причём совсем.
(Было предположение, что это как-то связано с «удалёнными» расширениями
У меня точно такая же проблема произошла, после удаления 5 из 6 расширений из базы. И есть BAK этой базы до удаления расширений 100% воспроизводимость, сейчас оформляю на v8@1c.ru . EDT тут ни причём совсем.
Спасибо за информацию, если не трудно, можете приложить номер ошибки, которую зарегистрировали на платформу, чтобы мы отследили, что с ней, и эту ошибку закрыли, пока просто понижу статут критичности
(Было предположение, что это как-то связано с «удалёнными» расширениями
У меня точно такая же проблема произошла, после удаления 5 из 6 расширений из базы. И есть BAK этой базы до удаления расширений 100% воспроизводимость, сейчас оформляю на v8@1c.ru . EDT тут ни причём совсем.
Спасибо за информацию, если не трудно, можете приложить номер ошибки, которую зарегистрировали на платформу, чтобы мы отследили, что с ней, и эту ошибку закрыли, пока просто понижу статут критичности
Код ошибки они не прислали, номер обращения HL-500056
Причин тоже не сказали, предложили способ как «вылечить» проблему, но у меня согласно их инструкции не получилось. У меня при попытке добавить изменить структуру регистра, на который они сослались реорганизация ИБ не проходит. Текст переписки, в нём нет ничего конфиденциального, прилагаю.
(#HL-500056) RE[8]_ После удаления расширений в работоспособной ИБ база перестаёт открываться в режиме 1С_Предприятия с ошибкой.zip
Отвечать я им более не стал, так как диалог мне напомнил разговор слепого с глухим. Я их спрашиваю про причины, они мне предлагают лекарство:
Мне нужно понять
что приводит к подобным ситуациям, какие мои действия были неправильные действия, почему расширения склеились.
Как это произошло сказать сложно. Восстановить сценарий поломки по сломанной когда-то, возможно уже достаточно давно, базы практически невозможно.
Можно предположить, что может помочь реструктуризация этого регистра.
Открываем конфигурацию, модифицируем регистр (как угодно, добавить ресурс). Сохраняем. <<—здесь у меня не получилось
Проверяем ТИИ. Ошибок нет.
Конфигурация работает. Можно удалить расширение IEX и все остальные.
да, посмотрел, не понятно, так как обращение Ваше уже закрыто, и я не могу понять делалось ли вообще что-то(
Labels
bug
Something isn’t working
Синхронизация с ИБ
Механизм синхронизации с инфо-базазой, приложения (applications)
В статье рассказывается про методы борьбы с ошибкой при выполнении файловой операции Ошибка при выполнении файловой операции /Params/DBNames.
Друзья, всем привет, в данной статье я хочу поделиться поиском решения проблемы
‘v8srvr://*ИМЯ_СЕРВЕРА*/*ИМЯ_БАЗЫ*/Params/DBNames’ .
Для чего мне понадобилась целая статья? Я перепробовал кучу решений, которые есть в открытом доступе, и ничего из этого мне не помогло. Решение проблемы у меня заняло целую неделю. И я не хотел бы, чтобы кто-то еще, возможно, так мучился. Так как база данных в моем случае весит более 300 ГБ, а каждая реструктуризация отнимает время, а обновить ее в файловом варианте, чтобы исключить ошибку, не получится.
Вводные данные.
База на SQL сервере 2014, платформа 8.3.20.
При обновлении, а именно переходе с 2.0 на 3.0 версию управляемые формы конфигуратор выдал эту ошибку.
Поискав на форумах информацию, я предлагаю вам рассмотреть различные пути ее решения.
Возможное решение № 1:
Обновлять каждый документ, справочник, реквизит справочника поочередно, пока не найдете проблемное место.
Очень долго и муторно, и я то пробовал, сначала справочники, потом документы. Но даже на справочниках выдавал ту же ошибку. Решение нашел тут же на сайте форума, вот ссылка https://forum.infostart.ru/forum72/topic287083/
Возможное решение № 2
Перевести базу в файловые вариант и обновить. На форумах пишут, что это помогает, если база небольшая. Но это не мой случай, такая большая база, как у меня, просто не загрузится из файла dt в файловый вариант.
Возможное решение № 3
Бывают проблемы с конфигурацией поставщика, если у вас она находится на поддержке. Для проверки этой гипотезы требуется зайди в пункт меню поддержка и сохранить конфигурацию поставщика в файл, если все ОК и сбоев нет, значит у вас все НОРМ.
А если нет, то требуется эту ошибку исправить. Можно попробовать снять с поддержки конфигурацию, обновиться через объединение, а потом загрузить измененную конфигурацию (которая у вас ранее не реструктуризировалась). Тут до кучи вариантов много. Обновиться с полного файла CF . Но я эту операцию тоже проделал, хотя конфигурация поставщика сохранялась в файл нормально и без ошибок.
Возможное решение № 4
Если вы подозреваете, что в конфигурации и в базе данные имеются логические ошибки, сделайте тестирование и исправление, кстати, я тоже это делал, мне не помогло. Также в конфигураторе через пункт меню Конфигурация сделайте Проверку конфигурации, в настройках поставьте логическую целостность.
Возможное решение № 5, которое помогло мне
А решение-то простое, уже пробовал почти все, и пришла мысль, может двойная реструктуризация и поэтому выходит ошибка или объекты конфигурации изменены из-за режима совместимости. Знаете же, когда снимаете режим совместимости, или переходите на другой, платформа изменяет структуру метаданных. Решил сравнить режимы совместимости в конфигурации базы данных и сохраненной конфигурации. В конфигурации был режим совместимости 8.2, а в сохраненной стоял режим совместимости в 8.3.14.
Но хотя это типовое обновление. А пустая CFка обновилась без проблем, но при обновлении в копии базы выдал эту ошибку
Вернулся к конфигурации БД, поставил ее в режим совместимости 8.3.14. Произвелась реструктуризация.
Обновил с ранее выгруженным файлом cf (сохраненной конфигурации) и все встало на свои места, база обновилось.
Механизм реструктуризации на сервере V2
Также я пробовал через механизм обновления 2.0, а именно Обновить конфигурацию базы данных на сервере, но там выдал другую ошибку, и я начал ее копать.
Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Неопознанная ошибка HRESULT=80004005
А решение пишут, что так же в конфигурации поставщика. Снять с поддержки, загрузить измененную конфигурацию, или обновиться с полного CF.
Если кому-то поможет статья, буду рад, сэкономить ваше время.
Обновлял как-то базу динамически — нарушилась целостность структуры… Из бэкапа восстановил таблицу dbschema и база заработала. Но потом оказалось, что если в один документ добавить реквизит, то база не обновлялась, вылетает ошибка. Скорее всего это из-за того, что в dbnames прописан столбец в этом документе, которого на самом деле не существует.. Вот я и хочу прочитать в таблице Params бинарную запись dbnames, изменить что мне надо и засунуть изменения обратно. Как это можно осуществить?
Рекомендую предварительно закупить пару банок вазелина
рискну предположить, что бинарник там — это хмл, но не факт а в обчем — не с той стороны ты начал бутерброд есть, дядя Федор, имхо
База работает нормально, все данные на месте. Проблема только в одном столбце одного документа, не дает метеданные этого дока менять..
С какой надо? Находил на форумах, что доставали данные и заменяли их. Но не раскрывалась сам механизм.. Читал, что данные надо разархивировать еще.
тестирование исправление? просто выгрузить-загрузить дт? что-то из этого пробовал?
Тестирование-исправление не помогло, всю ночь делалось. ДТ — выгружать — загружать, слишком долгая тема, да и места на диске мало сейчас (оставлю на последок).
с цфкой из бекапа можно попробовать объединить полностью. я бы такие действия в первую очередь попробовал, так как алгоритмы закрытые, что конкретно делают — хз. может возьмет и сформирует тебе dbnames по структуре базы, мало ли, что разрабы курили
тут не нужно особых знаний sql, топик неправильный.
тут SQL и не пахнет, причем тут знатоки SQL??
Хм, я вначале просто попробовал — выгрузил cf из бэкапа, загрузил на касячную базу — не помогло. Но это было до того, как я структуры таблиц SQL синхронизировал и заменил dbschema. Сейчас еще разок попробую. Но читать данные из SQL и записывать обратно — это было бы круто даже если бы и небыло у меня проблемы с базой..
Как не пахнет? Есть запись в SQL…. читать её, записать её, 1С… Те кто SQL 1С-овской постоянно зависает — наверняка знают как читать и записывать бинарные файлы..
запись dbnames сжата алгоритмом deflate
Спасибо. А в 1С-ке или delphi не находил примеров использования?
сначала пробуй простые способы потом используй лом и молоток
Мне интереснее научиться читать-записывать, да и время не жмет (документ не типовой)
А что хоть за ошибка то вылетает при обновлении? Какой текст?
вопрос по сути гениален, поддерживаю)
В процессе обновления информационной базы произошла критическая ошибка. по причине: Ошибка СУБД: Microsoft OLE DB Provider for SQL Server: Не удалось вставить значение NULL в столбец «_Fld28219», таблицы «StalTestZUP.dbo._Document22276NG»; в столбце запрещены значения NULL. Ошибка в INSERT.
Ну я вопрос задавал в форме, которая по сути знания текста ошибки не требует..
Вот мне и надо этот столбец «_Fld28219» Удалить…
у тебя похоже описание конфигурации не содержит инфы по полю _fld28219, так что придется лом брать. Спрашивается: зачем ломал конфу средствами скуля? Получил приключений на свою ж*пу
я структуры синхронизировал, только данные о структуре не синхронизировались до конца, вот и хочу досинхронизировать. Ничего тут страшного нет, данные не теряются. Это всего-то проблема с парой записей, которые надо удалить.
вообще то надо начинать с ConfigSave
Ты не понял. Есть таблица Params, в ней есть запись DBNames, в этой записи есть данные бинарные, в этих бинарных данных содержится инфа о конфе. Вот мне эти данные и надо поправить, а не удалить столбец..
С этого было начато, но не помогло, поскольку структура базы данных поменялась. Я конечное решение привел.
Как тут уже было сказано Надо мне научиться пользоваться алгоритмом сжатия, да и всё.
загрузи в файловую, выполнни все операции по профилактике(утилита ремонта таблиц, крушение битых ссылок, и т.д. в режиме тестирования/исправления) потом закугрузи в скуль «хорошую» другой путь копаться в дебрях скуля, но это путь когда вариант 1 не дал результата и последний на порядок гемморойней
я, конечно, может, глупость скажу, но пробовал ли ты ставить флаг нулл у столбца? и есть ли столбец?
Это я использую, если забью на SQL. Мне так интереснее, да и на будущее пригодится.
Инфа о наличии столбца находится в бинарных данных, в самой-же реальной структуре его просто нет.
организация таблиц и связей структур данных 1С в классических реляционных СУБД понятна только разработчикам платформы и людям, которые для них собирали грибы — удачи)
реквизит переименуй в конфигураторе и сохранись и обратно
Интересно это ноги растут отсюда или зайцы плакали но ели кактус?
Сделать копию базы без данных и экспериментировать на ней. Если получится починить, из копии перенести конфигурацию в рабочую базу.
У меня такая шляпа произошла когда при обновлении файловой базы вырубили свет. 2 недели попыток, восстановления этой таблицы прошли зря. Связей и структуры этой таблицы мне мне понять не дано. Хотя структура файла аналогична ALS-файлу. Но связи с другими таблицами я не нашел. Тестирование и прочие типовые средства либо ни чего не находят либо вываливаються с ощибкой. Не помню точно как победил. Но косяк был с недавно добавленным реквизитом. Поэтому вставил в файл cf-ник и DBSchema из копии, а потом тестирование и исправление.
в Ei это можно сделать. Да действительно отсутствующий столбец описанный в DBNames может приводить к ошибке. Но не единым DBNames,,,, более подробнее тут
DROP TABLE AdventureWorks2012.dbo.SalesPerson2 ; как пример смотри ничего не перепутай)))
Тэги: 1С 8
Комментарии доступны только авторизированным пользователям
На чтение 5 мин Опубликовано Обновлено
В работе с программным продуктом 1С: Предприятие иногда могут возникать различные ошибки. Одной из них является ошибка при выполнении файловой операции params dbnames. Эта ошибка может возникнуть при попытке выполнить определенную операцию, связанную с базой данных.
Ошибка params dbnames может быть вызвана различными причинами. Во-первых, это может быть связано с несоответствием версий программного обеспечения 1С: Предприятие и используемой базы данных. Если версии не совместимы между собой, то возможностей программы для работы с базой данных могут быть недостаточно.
Во-вторых, ошибка может возникать из-за неправильной конфигурации доступа к базе данных. Например, если у пользователя нет необходимых прав на доступ к базе данных или на выполнение определенных операций с данными, то может возникнуть ошибка params dbnames.
Для решения проблемы с ошибкой params dbnames необходимо приступить к идентификации и устранению причины. Обычно это требует внимательного анализа логов программы и базы данных, осуществления проверок на соответствие версий программного обеспечения и базы данных, а также корректировки настроек доступа к базе данных.
Важно помнить, что решение проблемы с ошибкой params dbnames может потребовать наличия определенных навыков и знаний, поэтому рекомендуется обращаться за помощью к специалистам в области программирования и администрирования баз данных.
Содержание
- Ошибка при выполнении файловой операции params dbnames: как исправить
- Возможные причины ошибки при выполнении файловой операции params dbnames
- Как исправить ошибку при выполнении файловой операции params dbnames
Ошибка при выполнении файловой операции params dbnames: как исправить
Ошибка при выполнении файловой операции params dbnames может возникнуть в программе «1С:Предприятие» в случае проблем с обращением к базам данных. Эта ошибка может возникать по разным причинам, но обычно связана с некорректными настройками или повреждением файловой системы.
Если вы столкнулись с ошибкой params dbnames, следуйте этим шагам для ее исправления:
- Перезагрузите компьютер. Иногда простая перезагрузка может решить проблему. Это позволяет очистить временные файлы и сбросить некорректные настройки.
- Проверьте целостность файловой системы. Воспользуйтесь программой для проверки ошибок на жестком диске, чтобы убедиться, что ваша файловая система не повреждена. Если обнаружены проблемы, исправьте их.
- Проверьте настройки доступа к базам данных. Убедитесь, что у вас есть права на доступ к базам данных. Проверьте настройки безопасности и разрешите доступ к необходимым файлам и папкам.
- Обновите программу «1С:Предприятие». Убедитесь, что у вас установлена последняя версия программы. Некоторые ошибки могут быть исправлены в новых версиях программы.
- Переустановите программу «1С:Предприятие». Если все остальные шаги не помогли, попробуйте переустановить программу. Убедитесь, что вы сначала полностью удалите предыдущую версию программы, а затем установите новую.
Если после выполнения всех этих шагов ошибка params dbnames по-прежнему возникает, рекомендуется обратиться в службу поддержки «1С:Предприятие» для получения дополнительной помощи. Специалисты смогут провести более глубокий анализ проблемы и предложить специфические решения.
Важно помнить, что перед внесением любых изменений в систему необходимо создать резервную копию данных, чтобы в случае неудачи можно было вернуться к предыдущему состоянию без потери информации.
Возможные причины ошибки при выполнении файловой операции params dbnames
Ошибка «params dbnames» может возникать при выполнении файловой операции в системе 1С:Предприятие. В большинстве случаев, данная ошибка указывает на проблемы с доступом к базам данных или неправильно настроенными параметрами.
Вот некоторые возможные причины ошибки:
- Неправильные настройки подключения к базе данных. Проверьте правильность указания имени сервера, порта, имени пользователя и пароля.
- Отсутствие доступа к файлам базы данных. Проверьте права доступа к папкам, в которых хранятся файлы базы данных.
- Неправильно указан путь к базе данных. Убедитесь, что путь к базе данных указывается корректно и соответствует спецификации системы 1С.
- Проблемы с сетевым соединением. Проверьте стабильность сети и отсутствие проблем соединения с сервером баз данных.
- Конфликт режимов работы базы данных. Убедитесь, что ни одна другая программа или пользователь не использует базу данных.
- Проблемы с установленными драйверами баз данных. Проверьте, что у вас установлены все необходимые драйверы и они настроены правильно.
Если вы столкнулись с ошибкой «params dbnames», рекомендуется последовательно провести проверку указанных выше причин. Обращайтесь к системному администратору или специалистам по 1С, чтобы получить помощь в решении данной проблемы.
Как исправить ошибку при выполнении файловой операции params dbnames
Ошибка «Ошибка при выполнении файловой операции params dbnames» может возникнуть в программе 1С при попытке выполнения операции с базой данных, связанной с параметрами файла params.dbnames.
Чтобы исправить данную ошибку, можно применить следующие шаги:
- Убедитесь, что файл params.dbnames существует в указанном месте. Проверьте путь к файлу и его наличие в системе.
- Проверьте права доступа к файлу params.dbnames. Убедитесь, что у текущего пользователя есть достаточные права на чтение, запись и выполнение операций с файлом.
- Перезапустите службу 1С или компьютер. Иногда проблемы с файловыми операциями могут быть вызваны временными сбоями, которые могут быть устранены перезапуском системы или соответствующей службы.
- Если вы используете сетевое подключение к базе данных, проверьте соединение с сервером баз данных. Убедитесь, что сервер работает исправно и доступен для подключения.
- Проверьте наличие ошибок в журнале событий 1С. Обратите внимание на любые сообщения об ошибках, связанных с файлом params.dbnames. Возможно, это поможет выявить проблему и ее источник.
Если вы проделали все вышеперечисленные шаги и ошибка всё равно продолжает возникать, рекомендуется обратиться к специалистам службы поддержки 1С или общественной группы по 1С. Они смогут оказать более конкретную помощь и решить возникшие проблемы.
Чудесатая ошибка при обновлении |
Я |
chihpyh
30.09.21 — 22:45
На MS SSQL крутится база УТ 11.4. Внес небольшие изменения в конфигурацию, пытаюсь обновить. При обновлении выдает ошибку
Ошибка при выполнении файловой операции ‘v8srvr://servername/basename/Params/DBNames’
Ошибка эта вылезает уже некоторое время и раньше я лечил ее выкидыванием всех пользователей и рестартом агентов. Однако, теперь это не помогает. Сделал вообще радикально: заблокировал запуск новых сеансов, регламентных заданий, но ошибка все равно проявляется. И что самое интересное, в тот момент, когда она возникает, в списке сеансов появляется какое-то фоновое задание.
Пытался выгрузить базу в dt, но при этом получил ошибку
server_addr=tcp://servername:1560 descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1674 file=srcDataExchangeTcpClientImpl.cpp
Создал из бекапа копию базы — там все отлично. На радостях пересоздал рабочую базу из того же бекапа — фигвам. Выяснилось, что у базы есть опубликованые веб-сервисы, подумал, что через них что-то цепляется. Отменил публикацию — воз и ныне там.
Куда еще можно покопать?
mikecool
1 — 30.09.21 — 22:48
я недавно поймал ошибку «выполняется системное регламентное задание», похоже — от сервера
chihpyh
2 — 30.09.21 — 23:29
(1) Вряд ли это мой случай
МихаилМ
3 — 30.09.21 — 23:38
«Куда еще можно покопать?» в сторону работы с технологическим журналом
chihpyh
4 — 01.10.21 — 00:26
Покопал. Эту-то ошибку я и без него получал
18:34.886000-0,EXCP,4,process=1cv8,OSThread=3928,Usr=Username,ClientID=2,Exception=NetDataExchangeException,Descr=’ server_addr=tcp://servername:1560 descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1674 file=srcDataExchangeTcpClientImpl.cpp’
chihpyh
5 — 01.10.21 — 00:28
Может быть, конечно, дело в этом
Ёпрст
6 — 01.10.21 — 00:38
(0) хотя бы серверный кеш очистил ?
>>> пересоздал рабочую базу из того же бекапа — фигвам
просто рестор сделал заместо рабочей базы и болт, так что ле ?
серый КТУЛХУ
7 — 01.10.21 — 00:40
chihpyh
8 — 01.10.21 — 14:22
(6) Да, просто восстановил. Кеш вроде каждую ночь чистится
(7) Там на память в основном кивают, памяти до пса, 64Гб оперативка, 100Гб свободно на С
Lama12
9 — 01.10.21 — 14:25
(8) Кэш на сервере каждую ночь чистится? Вы сервер приложений каждую ночь останавливаете или кэш чистите при работающем сервере приложений?
Kassern
10 — 01.10.21 — 14:26
(0) что поддержка 1с говорит по вашему дампу?
Lama12
11 — 01.10.21 — 14:27
ИМХО. Т.к. бэкап рабочий, все дело в кэше.
chihpyh
12 — 02.10.21 — 00:46
(9) Тут не очень в курсе, надо выяснять, админ этим занимается.
(10) Да вот как-то не обращался. А что, реально могут помочь? Имел, просто, негативный опыт обращения в техподдержку мегакорпораций (к мелкомягким), понял, что смысла нет. У 1С это лучше поставлено?
(11) Попробую почистить, но что-то не уверен, что поможет.
Придумал способ, как обновиться: остановлю сервер 1С, сделаю бекап в копию, там накачу доработки, сделаю бекап копии и накачу его на рабочую базу. Вот только очкую: что-то может пойти не так?
OldCondom
13 — 02.10.21 — 04:23
админ занимается кешем, программист копается в бекапах… Ты точно не запутался в том, что пишегь?
МнеТолькоСпросить
14 — 02.10.21 — 14:26
Было такое при демоническом обновлении. Раз 5-6 повторяешь, в какой-то момент все таки сохраняет.
chihpyh
15 — 05.10.21 — 23:05
(13) Да вопрос-то не в том, кто чем занимается. Вопрос в том, что не обновляется нифига… И я, и админ на удаленке обслуживаем, должностных инструкций не имеем, так, какая разница, кто чем занят? Где-то он меня подстрахует, где-то я его.
(14) Раньше помогало, теперь нет. И обновление не демоническое, а с выкидыванием всех и запретом новых сеансов
Содержание:
1. Об ошибке при выполнении файловой операции
2. Устранение «Ошибки при выполнении файловой операции» в 1С 8.3
1. Об ошибке при выполнении файловой операции
Приветствую, коллеги! В данной статье будет описана ошибка «Ошибка при выполнении файловой операции», и подробно рассмотрены способы ее устранения.
Когда происходит обновление конфигураций в 1С 8, по завершении обновления, часто появляется ошибка, которая гласит «Ошибка при выполнении файловой операции – файл не содержит доступных обновлений».
2. Устранение «Ошибки при выполнении файловой операции» в 1С 8.3
Рассмотрим методы, при помощи которых, можно устранить ошибку при выполнении файловой операции в 1С.
Итак, первый способ – это попробовать сделать обновление при помощи файлов по обновлению вида «релиз 1с*.cfu». Если это не помогло, то можно попробовать обновить систему при помощи общего файла вида «полный релиз 1С*.cf».
Вторым способом будет проверка на соответствие общей версии системы 1С с минимальными требованиями версии конфигурации 1С, которую обновляем.
Третий способ устранения ошибки при выполнении файловой операции в 1С – более сложный, но действенный. Необходимо открыть в конфигурацию от поставщика в режиме Конфигуратора. Если ошибка всё так же появляется, то необходимо удалить конфигурацию поставщика, а затем опять установить. По сути, в данном варианте «вытягивается» последняя, рабочая версия данной конфигурации и обновление будет завершено без ошибок.
Рассмотрим подробнее третий способ. Пусть у нас уже есть некоторая конфигурация 1С KORG 1-ой версии, которая работает, но нужно поставить 2-ю версию, то есть обновить версию конфигурации 1С 8.3. Когда происходит обновление, всплывает ошибка «Ошибка при выполнении файловой конфигурации». Порядок действий в этом случае:
1. скачать релиз 1С KORG с версией 1*.cf;
2. копируем нашу базу данных;
3. в конфигураторе, который соответствует обновляемой базе, переходим по пути: «Конфигурация → Поддержка → Настройки поддержки → Снять с поддержки». В случае, если кнопка для снятия с поддержки недоступна, необходимо сперва включить возможные изменения. После этого нужно дать согласие, если система 1С будет уточнять что-либо или подтверждать действия;
4. Далее переходим по следующему пути: «Конфигурация → Сравнить и объединить с конфигурацией из файла…». Здесь необходимо выбрать файл «полный релиз 1С KORG версии 1*.cf»;
5. Далее перед нами появится окно, в котором система 1С будет запрашивать постановление на учёт для поддержки, на это уведомление обязательно отвечаем согласием;
6. В случае, если наша конфигурация является типовой, откроется окно по сравнению конфигураций. В нем обязательно убираем все «галочки». Далее последует объединение конфигураций;
7. В новом окне кликаем на «Сохранить изменения»;
8. Ещё раз сохраняем базу данных;
9. Обновляем конфигурацию 1С стандартным способом.
Если всё сделать, согласно инструкции выше, то в вашей конфигурации 1С 8.3 «Ошибка при выполнении файловой операции» больше не возникнет. Спасибо за внимание!
Специалист компании «Кодерлайн»
Айдар Фархутдинов
Обновлено 15.10.2020
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Рунета Pyatilistnik.org. В прошлый раз мы с вами разобрали, что из себя представляет файловая система raw, и как ее исправить, чтобы восстановить свои данные. Двигаемся дальше и поговорим сегодня на тему капризности 1С, точнее на капризную работу в рамках Windows Server 2016. Я рассмотрю причину и устранение периодически повторяющейся ошибки на сервере 1С 8.3 «Ошибка при выполнении файловой операции«. Ее я стал встречать после обновления с Windows Server 2012 R2 д 2016. Думаю мой опыт сэкономит вам часик серфинга по интернету.
Описание проблемы
В моей компании заканчивается обновление операционных систем у виртуальных серверов, с Windows Server 2012 R2 на Windows Server 2016, я понимаю, что поддержка первых еще будет несколько лет, но хочется уже не делать это в последний момент, а слегка опережать, да и уже давно пора стремиться к Windows Server 2019. Сервера 1С не были исключением, обновление происходило по быстрому варианты. Тут подразумевается накатывание более новой версии ОС по верх старой, тут мы убивали двух зайцев:
- Получали свежую версию ОС
- Оставляли весь софт на сервере, и не требовалась его переустановка
В случае чего всегда можно было откатиться из снапшота на момент проведения работ, благо ESXI 6.5 это помогает делать в два клика. Все прекрасно обновилось и сервер зажил новой жизнью. В какой-то момент при запуске клиента 1С 8.3 на RDS ферме, стала появляться ошибка:
Ошибка при выполнении файловой операции
Устранение проблемы
Начав изучать данный вопрос мы не стали откатываться к бэкапу, так как данная проблема возникала не постоянно, а через некоторые промежутки и была вызвана явно не переходом на более новую версию операционной системы. Подняв исторические данные в системе заявок, я нашел похожую, где решением ошибки был перенос базы данных 1С на другой диск. Меня это заинтересовало и я стал прикидывать, что же могло быть в той ситуации. Через минут 20 я нашел одну закономерность, что на всех проблемных хостах был установлен компонент Windows дедупликации, как раз на тех дисках, где располагались базы данных 1С.
Я для тестирования отключил дедупликацию и вернул все в исходное состояние, и о чудо ошибка при выполнении файловой операции больше не появлялась. Все те же действия я произвел и на остальных серверах.
Вывод: Windows Дедупликация и 1С просто не совместимы друг с другом, это нужно запомнить
Из дополнительных методов я могу вам посоветовать еще очистку кэша 1С. Еще в на умных сайтах советуют на серверах, где используется 1С отключать протокол IPv6 на сетевых интерфейсах, но лично я не понимаю этого прикола, так как сама Microsoft советует по возможности этого не делать, в виду того, что очень многие ее сервисы и компоненты Windows в приоритете используют именно его, меньше будет проблем с DNS и Active Directory.
Вообще если у вас виртуальные сервера лежат на системе хранения данных, то у нее должна быть своя функция дедупликации и использовать лучше и правильнее ее. Если у вас есть другие варианты решения данной проблемы, то пишите их в комментариях. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Ошибка обновления базы в режиме 1С: Предприятие: Ошибка при выполнении файловой операции ‘v8srvr://server/Config/’ по причине: Ошибка при выполнении файловой операции Попытка поместить указатель на файл перед началом файла
Описание ошибки:
При обновлении конфигурации 1С: Комплексная автоматизация, ред. 1.1 при установке релиза 1.1.104.1 и запуска серверной базы в режиме 1С: Предприятие для завершения обновления релиза после согласия лицензионного соглашения возникла ошибка, которая фатально прерывала дальнейшую работу с базой:
Ошибка при выполнении файловой операции ‘v8srvr://ECO-SERVER2/1C-ECO82/Config/7ad7a83c-ceed-4eaf-871f-23830205ec2f.0’
по причине:
Ошибка при выполнении файловой операции ‘C:Usersadmin1CAppDataLocalTempv8_EBA6_7.tmp’. 131(0x00000083): Попытка поместить указатель на файл перед началом файла.
Найденные решения:
После подтверждения на продолжение обновления практически сразу же, в ближайшие секунды, долго ждать не приходилось.
Возникала ошибка. При повторном запуске базы в режиме 1С: Предприятие повторялось то же самое. Скрин не совсем тот, а уже сделанный позднее, когда ошибка себя проявила повторно, после обновления конфигурации другим релизом (об этом подробнее см. в конце публикации), но в точности иллюстрирующий ситуацию. Разница лишь в том, какой текст следует после «‘v8srvr://<имя_сервера>/<имя_базы>/Config/»
Вот полный текст ошибки
Сразу же при виде формулировки «Ошибка при выполнении файловой операции ‘v8srvr://<имя_сервера>/<имя_базы>/Config/7ad7a83c-ceed-4eaf-871f-23830205ec2f.0’ по причине:» рука потянулась выполнить «Тестирование и исправление базы данных»
Но, увы, тестирование не повлияло на ситуацию. Ошибка вновь возникала. И тут внимание обратилось ко второй половине формулировки ошибки: «Ошибка при выполнении файловой операции ‘C:Usersadmin1CAppDataLocalTempv8_EBA6_7.tmp’. 131(0x00000083): Попытка поместить указатель на файл перед началом файла.»
В этом пути явно присутсвует папка со временными файлами базы. Тогда было решено выполнить простую операцию удаления и добавления базы в списке баз, чтобы очистить пользовательские временные файлы, связанные с базой.
И это дало положительный результат. Обновление базы после этого было выполнено успешно.
P.S.
P.S.: ситуация имела повторное возникновение еще позднее (т.к. выполнялось продолжительное обновление конфигурации 1С: Комплексная автоматизация 1.1, было пропущено чуть более 20 релизов) но в сопряжении с ошибкой, очень похожей по формулировке на ту, что описана в описании ошибки Ошибка разбора XML: -[1,202] Фатальная ошибка: expected ‘>’ . Но, если ознакомиться с похожей ошибкой, то можно увидеть, что она тоже решилась в свое время удалением/добавлением базы в списке баз 1С: Предприятия 8, что очистило пользовательские файлы, связанные с базой и нормализовало дальнейшую работу без дополнительных действий, кроме тех, что описаны выше.
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
24-04-2019
Журавлев А.С.
(Сайт azhur-c.ru)
Ошибка 1С при выполнении файловой операции или Ошибка операции с файлом базы данных, возникает когда 1С не может получить доступ к файлу базы данных, не может найти папку с базой или создать в ней необходимые служебные файлы.
 |
| Ошибка 1C при выполнении файловой операции |
Здесь мы видим частный и явно описанный случай проблемы. После обновления Windows на компьютере с базой, бухгалтер со второй машины не смог зайти в базу. Программа выдала ошибку как на скриншоте.
Описание: «Вход пользователя не выполнен из-за ограничений учётной записи. Например, пустые пароли не разрешены; ограничено число входов или включено ограничение политики».
В рассматриваемом примере 1С явно указывает на возможные источники проблемы. После установки патча винда сбросила некоторые настройки сетевой политики безопасности, и по умолчанию перестала пускать пользователей с учёткой без пароля.
Чтобы починить, нужно на ПК с базой зайти в Панель управлени — Центр управления сетями и общим доступом — Изменить дополнительные параметры общего доступа — Все сети — Общий доступ с парольной защитой — установить флаг Отключить общий доступ с парольной защитой.
Если не хочется бродить в недрах панели управления, можно открыть редактор политик напрямую:
Пуск — Выполнить (или Win+R) — secpol.msc;
Переходим в Локальные политики — Параметры безопасности — Учетные записи: разрешить использование пустых паролей только при консольном входе устанавливаем значение Отключен.
Какие ещё причины могут вызвать появление подобной ошибки:
- Некорректная работа антивируса. Обычно этим периодически грешит Касперский: нужно добавить приложение 1С и папки с базами в исключение. Иногда помогает только полная переустановка антивируса.
- Некорректная настройка общего доступа к папке с базой: нет прав у конкретного пользователя или прав на запись/изменение в папку. Проверить это очень просто: нужно перейти в папку (можно скопировать путь из окна запуска 1С) и попробовать создать в ней любой файл. Хотя бы обычный текстовый документ. Если не получается или папка не открывается — скорее всего оно.
Рекламы в блоге нет, заметки я пишу из чистого энтузиазма. Но если статья оказалась полезной, вы можете поддержать блог, отправив символическую сумму через форму ниже. Ваша поддержка вдохновляет меня на создание новых статей.
Есть база на УТ 10.3.6.8 Заказали обновить её до последнего релиза. Пытался обновить последовательно. При попытке обновления до релиза 10.3.7.8 выскакивает ошибка «Ошибка при выполнении файловой операции». И открывается список релизов для которых подходит данное обновление. В этом списке есть, само собой, 10.3.6.8. Решил попробовать конвертнуть под 8.2 При конвертации опять вываливается ошибка «Ошибка при выполнении файловой операции», после чего база становится не работоспособной. Если делаю «Сравнение конфигураций» (сравниваю основную и конфигурацию поставщика) выскакивает такая же ошибка. Проверка ТИИ и chdbfl показывает что ошибок нет. Куда копать и что смотреть уже и не знаю.
кэш чистил? на другом компе пробовал?
Да. Даже не поленился, съездил к ним и притащил базу сюда. Думал может что повредилось при пересылке по мылу.
+2 пробовал на их компе, аналогично
выгрузка проходит успешно? а загрузка?
выгрузка и загрузка проходят нормально. без ошибок
а если cf ник накатить объединением?
для обновления снять с поддержки нафиг и все сделать правильно, для перехода на 8.2, попробовать на sql закинуть
Если пытаюсь внести какие либо изменения в настройку поддержки с такой же ошибкой закрывает окно настройки.
Там что бы так сделать надо конвертнуть для начала, а конвертация не катит. Залить в 8.1, там конвертнуть и выгрузить?
загрузить cf этого же релиза?
создать распред. узел, создать начальный образ, отвязать от главного..
сначала сравни, вдруг меняли
а попробуй, кстати, на неё chdbfl из 15-го релиза натравить
Блин не могу найти столь древний релиз или ещё более ранний.
1. грохни конфу поставщика 2. создай отдельный ЦФ 10.3.7.8 3. накати ЦФ из п.2 на базу без КП 4. профит?
Сволоч, ругается не принимая старый формат файла базы))))
Пытался, в этот момент вываливается с ошибкой.
А как грохнуть конфу поставщика?
тады так: выгрузи в старой платформе, загрузи на 8.2.15, и натрави новый chdbfl нутром чую, конфа поставщика подпорчена. вроде в новых chdbfl они это доделывали, чтобы проверял и исправлял
Ошибок не обнаружено. Но при попытке конвертации опять скотина матерится.
Конфигурация — Поддержка — Снять с поддержки
Ёпть!! Победил!!! В самом деле была подпорчена конфа поставщика. Снял с поддержки. Конвертнул базу под 8.2 Накатил сверку последний КФшник 10.3.15.9 ВСЕМ спасибо!!
Кстати да, думаю не один я с таким столкнулся.
Тэги: 1С 8
Комментарии доступны только авторизированным пользователям
0
— 31.10.2014 — 10:46
Люди добные и не очень, ай нид ваш хелп. Второй день мудохаюсь, а просветление не приходит.
Имеется база 1С 8.
платформа (8.3.5.1119)
конфигурация бухгалтерия (2.0.62.4)
крутится на терминалке в sql-базе
Для экспериментов сделал себе копию базы на том же sql-сервере (из бекапов рабочей). Далее, при попытке обновления базы из шаблона до 2.0.62.5 релиза получаю ругань:
«c:documents and settingsuserlocal settingtemp1v8_2b_2c.tmp»
Причем если, снять конфигурацию с поддержки, и внести какие-нибдуь изменения ручками, то все нормально сохраняется и работает.
Что делал:
— удалял, добавлял базу в консоли сервера;
— чистил этот самый temp, выставлял на него права всем все можно;
— игрался с путями к файлам sql-базы (пробовал создавать в разных папках, в т.ч. рядом с рабочей базой);
— открывать конфигуратор не на терминале, а на машине через сеть;
нифига не помогает.
И лишь когда создал файловый вариант базы у себя на компьютере локально, тогда ошибка вылазить перестала.
Но таки хочется понять, как с этим бороться? Ведь если не дай бог придется восстанавливать рабочую базу и оно вылезет, и чего делать тогда?
1
— 31.10.2014 — 10:54
т.е. вот такую ругань я имел в виду:
«ошибка при выполнении файловой операции ‘c:documents and settingsuserlocal settingtemp1v8_2b_2c.tmp’»
2
— 31.10.2014 — 17:43
с одной стороны, в файликах *.tmp иногда встречаются всякие вирусопакости, поэтому вроде бы исключать *.tmp из антивируса нельзя.
но, а с другой стороны, нафига вообще держать на сервере доброго каспера?
зы: это все к тому, что ты все прекрасно описал и платформу и конфигурацию и sql упомянул, и терминал.. молодец, чЁ.
только про антивирус на сервере ни слова. Про его наличие/отсутствие. про его настройки/исключения в случае наличия.
ни гу-гу.
3
— 01.11.2014 — 08:49
Нету антивируса на сервере. На локальной аваст стоит.
4
— 03.11.2014 — 00:27
все еще актуально
5
— 03.11.2014 — 17:07
проверить базу чинилкой не пробовали ?
http://helpme1c.ru/kak-sdelat-testir…-redakciya-3-0
http://1c-sfera.ru/index.php/adminis…-v-nej-oshibki
ЗЫ база в дт выгружается?
6
— 03.11.2014 — 20:21
Было такое же, кстати, недавно. Проверки ничего не находили, все выгружалось-загружалось, а при обновлении стабильно валилось с аналогичной ошибкой во временном файле.
Так и не решили, с админом искали и ничего не нашли в тот момент, потом та виртуалка рухнула, а на текущей вроде все обновляется.
На 8.3.4 было, кстати.
7
— 04.11.2014 — 10:07
Цитата:
Сообщение от 101 
ЗЫ база в дт выгружается?
в том то и прикол, что
Цитата:
Сообщение от gamletspb
И лишь когда создал файловый вариант базы у себя на компьютере локально, тогда ошибка вылазить перестала.
и да, на ошибки проверял, никаких проблем не обнаружено
8
— 04.11.2014 — 10:38
хмм мну бы посмотрел на бэкапирование обоими способами, скуль, выгрузка в дт
ЗЫ еще бы и конфигурацию отдельно в цф выгружал
9
— 04.11.2014 — 10:50
Цитата:
Сообщение от 101
хмм мну бы посмотрел на бэкапирование обоими способами, скуль, выгрузка в дт ЗЫ еще бы и конфигурацию отдельно в цф выгружал
я могу все это сделать, только что мне это даст в плане решения проблемы?
10
— 04.11.2014 — 11:07
(9) две разных копии БД и еще одну чистую конфигурацию
ЗЫ сдается мне что при переносе на другой сервер и залитие в SQL предварительно запустив исправление целостности на файловой базе — ошибка исчезнет
ЗЫЫ еще сдается мне проверку на обновление таки проверить … возможно конфигурация поставщика не была обновлена и/или не до конца, в похожих случаях пробую на копии накатить поверх ЦФ от полного нового релиза — пока помогало
11
— 04.11.2014 — 12:37
Мне кажется ТИИ ведь никак не проверяет конфигурацию поставщика?
А то в свете — (0) «Причем если, снять конфигурацию с поддержки, и внести какие-нибдуь изменения ручками, то все нормально сохраняется и работает» похоже на глюканувшую конфигурацию поставщика. так что (10) +
12
— 08.11.2014 — 20:44
Ну вроде удалось победить проблему, по крайней мере на тестовой базе все заработало.
Для этого пришлось выгрузить конфигурацию и ИБ в файл. Потом нафиг удалить(!) базу SQL, создать ее занова, и только тогда загружать в нее ранее выгруженные конфигурацию и ИБ. Перед загрузкой еще пришлось перезагрузить сервисы скуля и 1С, иначе вываливалось с ошибкой. При этом база ужалась в 10! раз (с 59Гб до 5Гб), обновление накатилось нормально, и вроде все данные на месте, ничего не поехало.
Что интересно, скульную базу, перед тем как полностью грохнуть, пробовал чистить и ужимать по всякому, но даже после удаления всех данных (путем удаления базы 1С в режиме очистки базы) ее размер оставался больше 50 Гб. При этом все проверки ТИИ проходили нормально. Вобщем, поразвлекался на выходных на славу. Всем спасибо за внимание, надеюсь кому-нибудь мой опыт будет полезен.