17.01.19 — 10:57
Уважаемые специалисты, подскажите пожалуйста новичку как исправить следующую ошибку: после обновления КА2 на последнюю версию (2.4.6.189), попытка сделать обмен РИБ заканчивается ошибкой
Ошибка при выполнении файловой операции ‘v8srvr://Server/base/configsave/7816e551-17d2-4fdb-ae2b-1a0bb118c764.99e23922-aa3f-46f2-b3ce-0b1716c16cde.new’
по причине:
Ошибка при выполнении файловой операции ‘7816e551-17d2-4fdb-ae2b-1a0bb118c764.99e23922-aa3f-46f2-b3ce-0b1716c16cde.new’
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: String data, length mismatch
HRESULT=80004005,
Я заглянул в таблицу configsave — она пустая.
1С 8.3.12.1790, MSSQL 2008R2.
1 — 17.01.19 — 11:04
не совсем понятно какие конкретно действия были в:
// попытка сделать обмен РИБ
можно раскрыть подробней, что делалось в этом РИБ перед тем как выдало ошибку?
2 — 17.01.19 — 11:08
(1) после обновления конфигурации КА2 в центре я открыл «НСИ и администрирование»-«Синхронизация данных»-«Настройки синхронизации данных»-«Синхронизировать» (т.к. база для обмена одна, то курсор стоял уже на ней). Обмен прошёл без ошибок на стороне центрального узла, но в базе-приёмнике ничего не изменилось, и в логе приёмника вышла ошибка из (0).
3 — 17.01.19 — 11:09
На всякий случай выполнил DBCC CHECKDB (‘base’);
получил
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘base’.
4 — 17.01.19 — 11:16
Ещё такой новичковый вопрос — я бы с удовольствием разбирал все возможные варианты решения проблемы, но вопрос очень горит, и у меня вопрос — базу центр я обновлял не совсем стандартно (не через поддержку, а через «Загрузить конфигурацию из файла». Я знаю что это очень нехороший способ, но такой тут регламент).
Могу ли я таким же способом («Загрузить конфигурацию из файла») обновить периферийную конфигурацию и закрыть проблему?
5 — 17.01.19 — 11:18
(4) а бакап у нее есть?
6 — 17.01.19 — 11:20
закрыть проблему — это хорошо. Но тренироваться на кошках!
7 — 17.01.19 — 11:22
ага! мне ясно почему такое должно было произойти. У тебя же обновления как оно есть не было! Это была загрузка, которая ничего никуда не регистрировала, но сами системные данные конфигурации изменены. Тут без вариантов нужно будет в периферийный узел грузиться прямо из файла конфиги.
8 — 17.01.19 — 11:24
(5) Бекап — есть. Вдобавок обе базы не рабочие, а для тестирования.
(6) я двумя руками за, но у бухгалтерии отчетность горит.
(7) большое спасибо! но почему в таком случае что-то пишется в configsave? Почему я уточняю — обновление я делаю строго по инструкции и там сказано, что после обновления центра выгружать изменения надо стандартным обменом.
9 — 17.01.19 — 12:39
если перед «стандартным обменом» в периферийную базу будет уже загружен файл конфигурации из Центра, то конечно, обязательно надо сделать стандартный обмен, чтоб пробить горячим тестированием, что вся процедура завершилась успешно. Ну и при обновлении, после обновления там же типовые процедуры изменяют данные в базе, которые точно также нужно синхронизировать перед началом нормальной эксплуатации баз пользователями.
ildary
10 — 17.01.19 — 15:44
(9) огромное спасибо за совет, вроде бы всё заработало.
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Содержание:
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 «Ошибка при выполнении файловой операции» больше не возникнет. Спасибо за внимание!
Специалист компании «Кодерлайн»
Айдар Фархутдинов
1C 8 Ошибка доступа к файлу v8srvr://Server1C/
/ConfigSave
Описание ошибки:
Ошибка возникла в процессе при попытке обновления релиза базы 1С 8:
Ошибка доступа к файлу ‘v8srvr://Server1C/BP_2.0/ConfigSave’
по причине:
Ошибка доступа к файлу
Найденные решения:
Ошибка возникла на релизе Платформы 1С 8.3.20.1674 при попытке обновления релиза базы Бухгалтерии ред. 3.0, работающей в серверном режиме, после обновления (перехода) с редакции 2.0 на редакцию 3.0. Т.е. сначала без проблем было осуществлено обновление с редакции 2.0 на 3.0, в частности на релиз 3.0.96.35. Потом, при обновлении с релиза 3.0.96.35 на 3.0.100.16, в процессе, возникла указанная проблема. Рассмотрим 3 примера того, как можно избавиться, устранить такую ошибку в 1С 8.
Рис. 1, 2. Возникновение проблемы Ошибка доступа к файлу ‘v8srvr://Server1C/BP_2.0/ConfigSave’ в базе 1С 8
Это описание условий, при которых возникла на практике проблема. Но по факту и опыту других пользователей — может возникать и при иных событиях и действиях в базе. Ниже приведено описание метода, который помог в частном примере, а так же еще 2 (два) случая, которые помогли в других ситуациях.
Итак, попробуем разобраться, как устранить проблему в 1С 8 «ошибка доступа к файлу v8srvr://Server1C/<имя_базы>/ConfigSave». Первое, что приходит в голову при подобных проблемах выполнить процедуру «Тестирование и исправление» базы данных 1С 8. В режиме конфигуратора в меню «Администрирование» запускаем через пункт меню «Тестирование и исправление…» информационной базы. Можно установить все флажки списка «Проверки и режимы:». Для сокращения времени выполнения были отмечены пункты «Реиндексация таблиц базы», «Пересчет итогов», «Реструктуризация таблиц базы», «Пересоздание автономной конфигурации», а «Проверка логической целостности расширений» — опционально в зависимости от того, есть ли у Вас подключенные расширения в базу или нет.
Рис. 3. Запуск процедуры «Тестирование и исправление» в базе 1С 8
Выполненное «Тестирование и исправление» помогло, так что после него база обновилась до следующего и до последнего актуального релиза.
Это было описание частного случая. Но, учитывая тот факт, что момент возникновения ошибки может быть другим, то ниже собрана информация по другим способам устранения «ошибка доступа к файлу v8srvr://Server1C/…/ConfigSave».
Первый из них по информации обсуждения с форума infostart «Ошибка при выполнении файловой операции v8srvr://….» заключается в том, чтобы выгрузить базу в архив и полученный архив снова загрузить в базу. Более подробно можно прочитать по указанной процедуре в статье сайта: Как создать архивную копию базы 1С 8 (бэкап базы). Восстановить из архива. Далее коротко. В режиме «Конфигуратор» в меню «Администрирование» — пункт «Выгрузить информационную базу…» выгружается база в архив-файл с расширением .dt. Далее порекомендую в дополнение загрузить в текущую базу архив в том же конфигураторе в меню «Администрирование» — «Загрузить информационную базу», например, пустой базы, чтобы все внутренние таблицы базы удалились. После этого уже загрузить ранее сделанный архив-файл .dt самой базы.
Нажатие на изображении увеличит его
Рис. 4. Описание способа устранения ошибки в 1С 8 Ошибка доступа к файлу ‘v8srvr://…/ConfigSave’
Второй способ, по информации с того же форума и еще по данным обсуждения «Ошибка при выполнении файловой операции» другого форума forum.mista заключается в регулировке, изменения параметра «network packet size» в настройках СУБД MS SQL Server, если используется непосредственно такой, до максимального значения 32767.
Рис. 5. Другая рекомендация для исправления возникновения ошибки Ошибка доступа к файлу ‘v8srvr://…/ConfigSave’
Как увеличить значение «network packet size» у MS SQL указано по ссылке в разделе «Using SQL Server Management Studio» под заголовком «To configure the network packet size option».
Рис. 6. Как изменить параметр «network packet size» у СУБД MS SQL
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
11-08-2022
Журавлев А.С.
(Сайт azhur-c.ru)
Обновлено 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с обновление ошибка при выполнении файловой операции params
- Описание проблемы
- Устранение проблемы
- 1с обновление ошибка при выполнении файловой операции params
- ошибка при выполнении файловой операции
- Ошибка при выполнении файловой операции RuntimeCacheVersions
Ошибка при выполнении файловой операции во время обновления
Пытаюсь обновить конфигурацию нетиповую УНФ сравнением-объединением из файла на платформе 8.3.14.1565. Ключевые релизы не пропущены.
Выходит ошибка (скрин 23) «Ошибка при выполнении файловой операции ‘имясервера/имябазы/params’ в момент обновления конфигурации базы данных.
Чистила кэш, обновляла конфигурацию поставщика, восстанавливала свежие копии и повторяла действия на сервере, памяти, как оперативной, так и на диске, хватает, снимала полностью с поддержки. Антивирус на сервере не мешает. Администратор в этот момент (и в другие разы попытки) никакого соединения не разрывал.
При попытке обновить эту конфигурацию на платформе 8.3.13.1644 выходит другая ошибка: «Ошибка обращения к серверу 1С:Предприятия. по причине: Сеанс работы завершен администратором. по причине: Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 11.0: Unspecified error HRESULT=80004005,» (скрин 30).
Когда руки уже опускались, попробовала объединять не все объекты метаданных, а по частям. Начала с регистров сведения, накопления, продолжила справочниками, документами и т.д. Делала все на копии чисто для выявлении ошибки, поэтому применяла обновления на конфигурацию БД. Иногда выходила та же ошибка файловой операции, значит ошибка была в выбранных объектах для текущей итерации. В итоге, она нашлась. Реквизит «Обрабатывается» в перечислениях «СтатусыОбработкиТТНВходящейЕГАИС», при том, что егаис у нас вообще не используется. Этот реквизит с обновлением удалялся. Даже без сравнения-объединения конфигурация не давала удалить его, очень долго шла реструктуризация и снова выпадала ошибка файловой операции. Без пометки на изменения этого реквизита база успешно обновилась.
Решение скорее не про частную ошибку, а про алгоритм поиска этой ошибки в совсем неожиданном месте.
Уже после обновления еще раз провели тестирование, и замудренно таки удалили этот злосчастный реквизит.
Источник
1с обновление ошибка при выполнении файловой операции params
Добрый день! Уважаемые читатели и гости одного из крупнейших 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С.
Я для тестирования отключил дедупликацию и вернул все в исходное состояние, и о чудо ошибка при выполнении файловой операции больше не появлялась. Все те же действия я произвел и на остальных серверах.
Из дополнительных методов я могу вам посоветовать еще очистку кэша 1С. Еще в на умных сайтах советуют на серверах, где используется 1С отключать протокол IPv6 на сетевых интерфейсах, но лично я не понимаю этого прикола, так как сама Microsoft советует по возможности этого не делать, в виду того, что очень многие ее сервисы и компоненты Windows в приоритете используют именно его, меньше будет проблем с DNS и Active Directory.
Источник
1с обновление ошибка при выполнении файловой операции params
Описание ошибки:
При обновлении конфигурации 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): Попытка поместить указатель на файл перед началом файла.»
В этом пути явно присутсвует папка со временными файлами базы. Тогда было решено выполнить простую операцию удаления и добавления базы в списке баз, чтобы очистить пользовательские временные файлы, связанные с базой.
И это дало положительный результат. Обновление базы после этого было выполнено успешно.
Источник
ошибка при выполнении файловой операции
Люди добные и не очень, ай нид ваш хелп. Второй день мудохаюсь, а просветление не приходит.
Имеется база 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-базы (пробовал создавать в разных папках, в т.ч. рядом с рабочей базой);
— открывать конфигуратор не на терминале, а на машине через сеть;
нифига не помогает.
И лишь когда создал файловый вариант базы у себя на компьютере локально, тогда ошибка вылазить перестала.
Но таки хочется понять, как с этим бороться? Ведь если не дай бог придется восстанавливать рабочую базу и оно вылезет, и чего делать тогда?
т.е. вот такую ругань я имел в виду:
«ошибка при выполнении файловой операции ‘c:documents and settingsuserlocal settingtemp1v8_2b_2c.tmp’» с одной стороны, в файликах *.tmp иногда встречаются всякие вирусопакости, поэтому вроде бы исключать *.tmp из антивируса нельзя.
но, а с другой стороны, нафига вообще держать на сервере доброго каспера?
зы: это все к тому, что ты все прекрасно описал и платформу и конфигурацию и sql упомянул, и терминал.. молодец, чЁ.
Источник
Ошибка при выполнении файловой операции RuntimeCacheVersions
На данный момент релизы такие:
Конфигурация РАРУС: Ломбард 4.0.115.2;
Платформа 8.3.19.1467.
Режим работы файловый.
А проблемы начались еще на 8.3.18 и чуть более старом релизе конфигурации.
Соберу полный анамнез.
8.3.18 стояла уже больше года, конфа не обновлялась с декабря. С декабря по май никаких проблем не было. В мае случилась беда с компом — перестали открываться любые исполняемые файлы. Комп отвозили в сервис. Что уж там делали — я не знаю, клиент сказал, что «меняли систему, сохранили все, как вы просили». Но лично я не увидел, чтобы система переустанавливалась, может восстановили версию, не знаю) просто есть факт, что были такие проблемы.
Далее в июне ко мне обратились с ошибкой в этой базе:
Ошибка решилась чисткой кэша и служебных файлов в папке с базой.
Потом ко мне до вчерашнего дня не обращались. Теперь ошибка такая:
Со слов бухгалтера, ошибка возникает уже примерно месяц с некоторой периодичностью, но ей получалось ее решать то перезапуском сеанса, то через chdbfl(говорит, нагуглила такое решение, прошаренная блин), то через ТиИ со всеми галочками.
А сейчас вот ошибка просто не дает работать — может при старте сеанса вылезти(редко), может при записи объекта, может просто при открытии какой-либо формы. Причем важно, что ошибка возникает именно в разделе «Ломбард». Типовые документы проводятся, закрывается период, формируется оборотка — все без ошибок.
Что я пробовал делать: чистка кэша, перенос файла в новую папку, выгрузка/загрузка dt, размещение базы на другом физическом диске, chdbfl ошибок не выдал, соответственно обновление платформы и релиза конфигурации.
К сожалению на другом компе потестить не получится, т.к. отраслевая лицензия, будь она не ладна.
Из таких косвенных моментов, которые еще были: со слов бухгалтера, ошибка стала возникать через 3-4 дня после того, как им специалист раруса поставил новую конфигурацию «Ломбард ЕПС». Я не знаток в лицензировании раруса и без понятия, могут ли конфликтовать лицензии двух разных продуктов, но просто как факт. К слову., Ломбард ЕПС работает нормально.
Из того, что думаю попробовать:
1) Попробовать клиент-серверный вариант;
2) Поразбираться с отраслевыми лицензиями, попробовать их как-то переустановить (хотя знаю, что когда с лицензиями есть проблемы, то ошибки все-таки прямо об этом говорят.
3) Вариант, который совсем не нравится — это переустановка винды. Потому что там у них помимо баз туча всяких сертификатов ЭЦП, которые переустанавливать не хочется от слова совсем. Тут возможно промежуточным шагом будет попытка развернуть базу на другой машине с переносом лицензии. Хотя бы поймем, с базой проблема, или с компьютером.
4) Разворачивать стару копию без ошибки, переносить туда документы за период. В целом вариант ничего такой, но в предметной области не силен, кроме как обороткой проверять, корректно и до конца ли все перенеслось с точки зрения ломбарда — хз как.
Но прежде чем к этим радикальным мерам переходить, хотелось бы услышать ваши советы, может быть кто-то побеждал эту ошибку какими-то методами
Источник
кэши чисти перед процессом.
чистил, вплодь до сноса папки с профилем
и хитрый скрипт запускал, который перезаписывает configsave
помогла следующая инструкция Недостаточно свободной памяти на сервере 1С:Предприятия Проблема случилась на Платформе 8.1, Конфигурации Бухгалтерия предприятия. После разнесение сервера 1С:Предприятия и SQL-сервера на разные машины при загрузке dt-файла в базу расположенную на SQL-сервере стали получать ошибку «Недостаточно свободной памяти на сервере 1С:Предприятия». Решение проблемы: 1. При возникновении ошибки перезапустить службу сервера 1С. 2. Использовать много процессов(В свойстах кластера поставить галочку «Много процессов»). Добавить рабочие процессы, оптимальное значение 4-5 процессов. 3. Использовать регламентный перезапуск рабочих процессов. Но это не снимет проблему. Просто сократит «утечку» памяти. 4. Для операций с базой данных, например копирование базы данных использовать средства ms sql, а не работу с файлами dt. 5. Включите запись событий DBMSSQL в Технологический журнал (Смотрите текст файла «logcfg.xml» ниже или воспользуйтесь обработкой с ИТС НастройкаТехнологическогоЖурнала.epf) и определите, на загрузке какой таблицы происходит ошибка. Если config, то выполните загрузку в файловый вариант и очистку конфигурации поставщика: 5.1 Для этого надо проверить конфигурацию на наличие некорректной информации. Для этого следует выполнить команду меню Конфигурация — «Проверка конфигурации» (НЕ ТЕСТИРОВАНИЕ!) с ОДНИМ установленным флажком «Проверка логической целостности конфигурации». При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически 5.2 Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении («Удалена некорректная информация о метаданных»), значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. Добавление рабочего процесса Добавление рабочего процесса, в отличие от просмотра, возможно, только для конкретного сервера кластера. Для добавления нового рабочего процесса сервера кластера следует выбрать в дереве центральных серверов требуемый сервер, выбрать требуемый кластер, выбрать требуемый сервер кластеров выбрать ветку «Процессы» и выполнить команду контекстного меню «Создать — Процесс», галочкой Включить процесс. По поводу перезапуска рабочих процессов — с какого момента начинается отсчет указанный в настройке кластера? С момента старта процесса. Например стартовал в 18:00:00. Период перезапуска 86400 секунд, т.е. 24 часа. Соответственно через сутки в 18:00:00 процесс остановится и будет создан новый процесс. Как включить запись событий DBMSSQL в технологический журнал? Файл C:Program Files1Cv81inconflogcfg.xml должен содержать: Код
к сожаления источник потерял
Ошибка 1С при выполнении файловой операции или Ошибка операции с файлом базы данных, возникает когда 1С не может получить доступ к файлу базы данных, не может найти папку с базой или создать в ней необходимые служебные файлы.
Ошибка 1C при выполнении файловой операции |
Здесь мы видим частный и явно описанный случай проблемы. После обновления Windows на компьютере с базой, бухгалтер со второй машины не смог зайти в базу. Программа выдала ошибку как на скриншоте.
Описание: «Вход пользователя не выполнен из-за ограничений учётной записи. Например, пустые пароли не разрешены; ограничено число входов или включено ограничение политики».
В рассматриваемом примере 1С явно указывает на возможные источники проблемы. После установки патча винда сбросила некоторые настройки сетевой политики безопасности, и по умолчанию перестала пускать пользователей с учёткой без пароля.
Чтобы починить, нужно на ПК с базой зайти в Панель управлени — Центр управления сетями и общим доступом — Изменить дополнительные параметры общего доступа — Все сети — Общий доступ с парольной защитой — установить флаг Отключить общий доступ с парольной защитой.
Если не хочется бродить в недрах панели управления, можно открыть редактор политик напрямую:
Пуск — Выполнить (или Win+R) — secpol.msc;
Переходим в Локальные политики — Параметры безопасности — Учетные записи: разрешить использование пустых паролей только при консольном входе устанавливаем значение Отключен.
Какие ещё причины могут вызвать появление подобной ошибки:
- Некорректная работа антивируса. Обычно этим периодически грешит Касперский: нужно добавить приложение 1С и папки с базами в исключение. Иногда помогает только полная переустановка антивируса.
- Некорректная настройка общего доступа к папке с базой: нет прав у конкретного пользователя или прав на запись/изменение в папку. Проверить это очень просто: нужно перейти в папку (можно скопировать путь из окна запуска 1С) и попробовать создать в ней любой файл. Хотя бы обычный текстовый документ. Если не получается или папка не открывается — скорее всего оно.
Рекламы в блоге нет, заметки я пишу из чистого энтузиазма. Но если статья оказалась полезной, вы можете поддержать блог, отправив символическую сумму через форму ниже. Ваша поддержка вдохновляет меня на создание новых статей.