1c config runtimecacheversions ошибка
Приветствую, коллеги! В данной статье будет описана ошибка «Ошибка при выполнении файловой операции», и подробно рассмотрены способы ее устранения.
Когда происходит обновление конфигураций в 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 «Ошибка при выполнении файловой операции» больше не возникнет. Спасибо за внимание!
При обновлении стала выходить ошибка "Ошибка выполнения файловой операции", далее выходит окно "Файл не содержит доступных обновлений", хотя в списке есть наш релиз.
Конфигурация ЗУП 3.0, включена возможность редактирования - добавлены свои новые объекты, только для некоторых объектов включена "Редактируется с сохранением поддержки", остальные "Не редактируется".
Пробовал снимать с поддержки, далее объединил с типовым релизом, проблема как бы ушла, обновление пошло. Но все типовые объекты конфигурации стали с признаком "Редактируется с сохранением поддержки", хотя по идее у меня было таких объектов не более 5 наверное.
Как-то можно решить эту проблему, чтобы и обновление было возможно и объекты были "Не редактируется" как раньше.
(1) Sergey_SP, если обновления не проходят а в списке указан подходящий релиз , то скорее всего у вас не обновилась конфигурация поставщика. Вам нужно посмотреть через меню конфигурация -поддержка-настройка поддержки какого релиза у вас конфигурация поставщике и какой релиз основной конфигурации ( справка о программе) они должны совпадать
(2) vadim1011985, нет дело не в этом, релизы совпадают. по поводу остального (временные файлы чистить, базу перенести на другой ПК и т.д.) всё уже пробовал.
К (1) - Ещё можно посмотреть, активен ли в меню "Конфигурация" пункт "F7 Обновить конфигурацию базы данных". Если активен - снять бэкап, копию папки с базой и попробовать применить.
Чтобы вернуться на поддержку, надо выгрузить cf из типовой базы нужного релиза, полностью снять базу с поддержки и загрузить типовой cf через "Конфигурация" - "Загрузить конфигурацию из файла". Разумеется, сначала на копии базы.
(5) Sergey_SP, значит сначала делаете 100% типовую базу, частично снимаете с поддержки, перетаскиваете мышкой или копипастом все свои наработки, можно и сравнить объединить попробовать.
Потом выгрузить CF и уже его по выше описанной схеме применить к базе
(1) Sergey_SP, "Пробовал снимать с поддержки, далее объединил с типовым релизом " отсюда и ноги растут. Объединение и обновление - разные вещи. Вы проверьте в конфигураторе релиз конфигурации поставщика и релиз конфигурации БД. Не справка - о программе, а в свойствах.
(1)Добрый день!
А может быть такое, что, например, синоним у базы поменяли перед последним обновлением?
Хотя скорее всего правы в (8) и (9) - проблемы с конфигурацией поставщика.
(10) Если просто синоним, то должна конфигурация поставщика открываться нормально, ей же не важно какой синоним. В моем случае на любое действие с конфигурацией поставщика эта ошибка была.
Сталкивался с такой же проблемой, при чем с несколькими базами у разных клиентов, конфигурации Бухгалтерия 3.0 и ЗУП 2.5, базы серверные MSSQL. Проблема в том, что по каким-то причинам "рушится" конфигурация поставщика. При этом в настройке поддержки она показывается как правильная версия, но при попытке сравнить с конфигурацией поставщика или сохранить ее в файл, тоже вылетает эта же ошибка, при попытке открыть конфигурацию поставщика - ошибка и открывается пустая конфигурация. Предыдущие обновления проходили в штатном режиме, без ошибок. Т.е. причина ошибки не понятна. Лечил как уже писали выше, снятием с поддержки и загрузкой типовой конфигурации через Загрузить конфигурацию. Если база измененная, подготавливаем типовую, в нее добавляем свои объекты, обязательно копи-пастом и загружаем. С двумя такими базами все норм. С одной проблема повторилась через два-три обновления. В одной базе при загрузке типовой конфигурации не находило соответствия нескольким регистрам сведений, т.е. удаляла существующий и добавляла новый из типовой. В моем случае было не критично, но возможна потеря данных, так что не забываем бэкапиться перед исправлениями.
Smallrat; Hoper1981; Andreyyy; dima_gsv; MikZ; ram3; user992178; Somebody1; SkyOl; Nik_Name; + 10 – Ответить
Последнее время регулярно с этим сталкиваюсь. Скачиваю обновления, разворачиваю на съемном диске, устанавливаю, копирую CFU. Потом готовую папку отправляю в облако. Пытаюсь обновить с диска - файловая ошибка, нет доступных обновлений, а когда взял из облака, отлично обновилось. Ну ладно, повредился файл. Взял в облаке, скопировал к себе. Не обновляет. Сравниваю, размер один в один, еще раз копирую, фиг. Из облака отлично обновляет. Начал грешить на диск. Перенес данные, проверил диск, форматнул на всякий случай, вернул. Возвращал в другом порядке. Заработало. Скачал следующее, опять тоже, с этого диска отнес на облако. С диска не работает, с облака пожалуйста. Ладно умер диск, отложил взял другой, другой фирмы, другого размера. Сегодня та же хрень.Развернул на диске, скопировал в облако. На диске не работает, в облаке чудесно. Стер папку, скачал обновление вновь, развернул, достал CFU - НЕ РАБОТАЕТ. Ну не могут два диска одинаково умереть. Причина в чем-то другом.
Мучаемся с этим уже пару лет. Конфигурация УПП 1.3, на поддержке с возможностью редактирования. База на MSSQL 2008R2. Запрос в техподдержку результата не не дал. Недельная переписка. отправка базы и т.п.
Платформа 8.3.10, началось еще с 8.2. Разницы никакой. Танцы с бубном вокруг снятия/установки поддержки, обновления в штатном режиме и через некоторое время все по новой. Держу на готове пустую базу с типовой последнего установленного релиза. Выгружаю оттуда конфигурацию поставщика и накатываю на свою.
Надоело просто жуть. Но решения так и не нашли пока.
Уж по скольку занялся этой темой выложу свои мысли, так сказать в качестве "Бреда" сюда.
Анализировал таблицу [dbo].[Config] . На сколько мне известно самая жирная запись и содержит конфигурацию поставщика (но это не точно :) ). Технология хранения мне мало известна, по этому все сказанное лишь догадки.
Так вот, в испорченной базе, в этой самой жирной сроке (у меня она больше 314 мб) обнаружил, что большая часть этой строки (72%) состоит из повторяющихся блоков "3C2D554E494E495449414C495A45442D3E". В копии базы того же релиза этого нет.
Выгрузил ее сначала в символьном виде.
Потом выгрузил в бинарном виде и понял, что текст "".
Проводил эксперимент с копией базы. Если снимать конфигурацию с поддержки, то эта строка полностью не очищается. Становится меньше значительно, но полностью не очищается. Могу предположить, что в ней живет не только конфигурация поставщика. И удалять ее (как читал где-то в интернетах) я бы не стал, дабы не грохнуть рабочую конфигурацию.
Суть задумки проста. Хочу хранить конфигурацию поставщика в резерве и в случае такой напасти опять, просто скопировать в нужное место. (мало вероятно, но вдруг прокатит) Уж больно надоело танцевать с бубном.
Остались вопросы.
1. Где почитать про технологию хранения метаданных 1С v8.3 (SQL)?
2. Какова природа возникновения этой проблемы?
3. Не виновато ли в этом динамическое обновление конфигурации?
Столкнулся с такой же проблемой. Что сделал:
1. Взял типовую конф-ю того же релиза
2. Включил в ней возможность редактирования с сохранением поддержки для всех объектов
3. Натянул на нее cf сохраненный из проблемной базы, принял изменения
4. Сохранил конф-ю после объединения
5. Загрузил сохраненную конф-ю в проблеммную базу, принял изменения (при принятии были предупреждения, похоже это те объекты метаданных, которые умерли в конф-ии поставщика)
6. Профит, обновление прошло нормально.
снять с поддержки, загрузить cf такого же релиза, база встанет на поддержку сама и, после загрузки cf, можно обновляться дальше без проблем.
на sql все отработало.
А я сформировала файл обновления (чтобы все настройки сохранились), потом его же загрузила через "загрузить конфигурацию". И потом дальше обновляла без проблем. Отработало на файловом режиме
Тоже столкнулся с ошибкой "Ошибка выполнения файловой операции". При попытке обновить конфу файлом .cfu поставщика (Поддержка - Обновить конфу).
Так же, решилось восстановлением конфигурации поставщика.
Порядок по памяти:
1) сохранил имеющуюся конфу в .cf
2) загрузил конфу поставщика (.cf) с поставкой на поддержку (изменения не принимал)
3) включил в конфе возможность редактирования с сохранением поддержки для всех объектов
4) накатил свои наработки из конфы .cf на (1) шаге с помощью сравнения-объединения
5) принял изменения
Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .
Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.
Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :
Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) - результат тот же, pg_dump не может нормально создать архив.
При постановке конфы обратно на поддержку архивация начинает работать нормально.
Как можно решить проблему?
(0)[Как можно решить проблему?]
invalid memory alloc request size 1174829507
видимо копать нужно от сюда
Проводил эксперимент:
1. Выгружаю конфу поставщика в cf.
2. Из цф создаю чистую базу.
3. Запускаю pg_dump - архивация проходит нормально.
4. В этой же конфе включаю возможность изменения.
5. Запускаю pg_dump - архивация проходит НЕ нормально.
(7) Был у меня клиент пару лет назад. Жаловался на похожие траблы. Поскольку ему нужно было хоть какое-то решение, то ему пришлось делать все такие штуки непосредственно в линуксе - под виндой уже не работало.
Именно с конфигой на КА 1.1 .
Если кто имеет возможность провести эксперимент (6), попробуйте и напишите о результате. На все про все нужно 15 минут на нормальном компе.
Я пробовал на WinServer 2008 R2 и Win7 .
(2) Вроде как у Postgres лимиты не маленькие :
Максимальный размер таблицы - 32 TB
(0)
Покажи скрипт, как бэкап делается.
[проблемы с архивацией]
не путаешь понятия дампа и архива? Проблемы именно с архивацией?
"C:\Program Files\PostgresPro 1C\9.4\bin\pg_dump" -U postgres -F c -Z9 -c -f C:\arc\arc_pg\ara_backup.backup bs
ren C:\arc\arc_pg\ara_backup.backup bs_%f_name%.*
(15) Снятие с поддержки любой другой конфигурации также приводит к такой ошибке? Или только КА указанной версии?
(18) немного не так - если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть.
з.ы. Трабл именно при снятии с "замка" и при сохранении поддержки
(18) Именно в версиях КА 1.1.107.3 и 1.1.107.4.
В КА 1.1.106 проблемы еще нет.
Попробовал уже с типовыми демоконфами КА - все так же.
Т.е проблема не в моей базе , а в конфигурации конкретной версии.
(19) Я понимаю. У нас бухгалтерия и зарплата в таком режиме поддержки уже много лет, ничего подобного никогда не возникало. Правда, и сервер приложений и СУБД на Linux(тоже много лет).
(19) [если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть]
А что за ограничение в этом случае срабатывает?
(25) твой же пост:
-*-
Вроде как у Postgres лимиты не маленькие :
(31) я бы чисто ради интереса грохнул что-нибудь из конфы, чтоб привести размер cf к 0.99Гб, и проверить еще раз бэкап. (что там есть такого, макеты с двоичными данными, какие-нибудь)
(32) да я ж и предлагаю - снять с поддержки полностью и размер в два раза упадет и проблема должна уйти, если это в ней причина.
Но это ни одного там в ней изменения нет, когда вкл изм и накидать туда макетов огромных, то будет больше, конечно.
з.ы. Все-таки я думаю, что в КА 1.1 там не прямая зависимость с размером, а с самим наличием "второй копии" конфигурации, которая конфликтует с "первой" при запихивании ее в БЛОБ платформой - просто глючит в данном случае при попытке архивации баз, а так оно и в других событиях глючит тоже. При накатывании обновлений из Поддержка-Обновить конфигурацию, например.
(40) [ просто глючит в данном случае при попытке архивации баз]
+100500
проблема Postgres, с MS SQL её нет
(40) Такая же проблема должна быть и под линуксом. Ведь лимит на размер поля у Postgres одинаковый для обоих версий.
таблицы "config invalid memory alloc request size 1174829507
можно и дальше позаниматься флюдом, но тема закрыта
т.е. дело однозначно в размере cf
BLOB побился явно. Перезагрузить конфу прямой загрузкой.
(47) попробовать можно, но в тех вариантах не помогало, на которые я ссылался, что ошибки с КА 1.1 возникали в серверном режиме.
я сегодня проверю вариант с большой конфигой по размеру (ка_2.4) на субд постгри и сервером на винде - сглючит или нет - проверю. Не знаю только получится ли протестить, если сервер для субд будет линуксовый. долго такое городить и профита не будет чисто поэкспериментировать и прокачать экспу разве что :-)
"C:\Program Files\PostgreSQL\10.3-2.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "D:\1cBackupNew\BUH_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup" "BUH"
Вырезал из конфигурации несколько макетов ненужных драйверов.
cf сократил до 0,98 Гб. Но проблема с архивацией осталась.
(64) гугл упорно говорит, что таблица битая. Я бы уменьшил ее еще, но значительно - до 500мб, например, и еще раз пг_дамп. Это подтвердит битая или нет
можно предположить, что источником ошибки и вовсе окажется некий конкретный объект метаданных, только сколько раз надо провернуть все-все-все манипуляции, чтоб найти такой объект. Причем, сбоить этот объект начинает в процессе клонирования конфиги поставщика в подкопию основной ЦФ-конфиги
(66) Похоже ты прав.
Развернул демоконфу КА2, включил возможность изменения - в результате cf размером 1,2 Гб.
Архивация проходит без проблем.
Такая же проблема. dt делается. в копию серверную(Postgres pro 9.6) не грузится, ругается на память, а в файловую загрузился. Пытаюсь определить проблемный объект в метаданных. Попутно попробую в mssql 2008 загрузить dt.
(75) А я бы просто оставил базу с полностью снятой с поддержки, а обновления заготавливал по мере необходимости из файлового режима. Какая разница, если развернута тестовая копия и завершить процедуру обновления все равно нужно только на тестовой, а затем уже из тестовой забирать CF и обновлять продакшн базу сравнением/объединением.
(76) как сейчас решение да, но причина явно не устранена. попробую 107.5 накатить на файле и перенести на серверную.
В MsSQL действительно все загружается без ошибок. Проблема на стороне Postgres, попробую покопать настройки. Ни у кого нет опыта тонкой настройки? Не хочется верить, что Postgres настолько не продуман.
(78) никто и не заставляет. Только две конфиги КА 1.1 и УПП 1.3 - с остальными проблем нет. с КА 2.4 тоже проблем нет.
(79) этому косяку уже много лет.
Раньше была проблема на 32-ух битных версиях PostgreSQL, не хватало им памяти для больших конфигураций. Приходилось снимать с поддержки конфу, чтобы работать. С появлением 64-битной проблема ушла.
И вот опять что-то похожее.
Насколько я разобрался 1С пихает файл конфигурации в поле. Поле имеет ограничение 1 Гб. Размер конфы закрытой для ред. и снятой с поддержки не превышает 1 Гб, а частично дописанная превышает. 1С рекомендует (прочитал на форуме SQL) снимать с поддержки полностью или использовать pg_basebackup. Снял на тестовой с поддержки - дамп отработал без ошибок.
(87) Просто рекомендация 1С не совсем честная. Если снять конфу КА 1.1 с поддержки или УПП 1.3 с поддержки, то проблема действительно пропадает. Однако, есть другие конфы, с которыми этой проблемы в принципе нет - см (74),
а так же и другие.
(89) и решения от 1с скорее всего не дождемся. Работу с данными в этом случае организует кластер серверов 1с? имею в виду структуру таблиц.
(87)В тему: те же проблемы с УПП 1.3.112.4 на pg 9.6:
-при архивировании средствами pg - описанная выше ошибка
При анализе выяснилось, что ошибка возникает с таблицей config (конфигурация БД), при обработке определенной строки таблицы, подробности ниже.
1. Просмотрел таблицу config, поля: filename (строка), creation (датавремя), modified(датавремя), attributes(целое), datasize(целое), binarydata(bytea).
2. Строк 34017.
3. Сумма размера бинарных полей примерно 98% размера файла .cf (остальное занимают оставшиеся поля), т.е. в binarydata хранится конфигурация.
4. Проверил: для любой строки размер binarydata не более 100МБ. Кроме одной, там размер binarydata 555МБ. И именно в этой строке возникает ошибка. Выяснил, что в данной строке, в одном поле хранится конфигурация поставщика.
5. Поэтому при снятии с поддержки или запрете изменений (замок) ошибка исчезает, т.к. при этом удаляется строка по п.4.
Суммируя вышеизложенное: максимальный размер данных, внесенных в ОДНО поле - 0,55ГБ (см. п.4.), что не дотягивает до озвученного лимита объема данных в ОДНОМ поле 1ГБ.
Вывод: либо лимит объема ОДНОГО поля около 0,5ГБ, либо причина в другом.
Пробовал играть настройками конфигурации pg (размеры буферов памяти и т.п.) - ошибка не исчезла.
(92)Кстати, и обычный select средствами pg вызывает эту же ошибку, если в его результате содержится поле Binarydata с конфигурацией поставщика (555МБ) - еще одно подтверждение что ограничение 1ГБ ни при чем.
(0) ровно та же проблема у меня была с УПП в 2012 году - с той же ошибкой pg_dump грохался. Стабильность - признак мастерства, чо. Сколько лет прошло, а ничего не меняется.
(96) отписывались. Я помню об этих глюках примерно с 2011-2012 годов. Когда это поперло, то начали откладывать на ИТС полные дистрибы КА 1.1 и УПП 1.3 , т.к. реально был всплеск обращений, что не проходит процедура обновления конфиги апдейтами.
Внимание! Это техническая часть, не предназначенная для публикации. Всё про очистку кэша баз 1С читайте вот в этой статье.
Технические нюансы
Каково различие между AppData/Local и AppData/Roaming?
Local содержит файлы, созданные в процессе работы установленных программ. Эта информация строго специфична для конкретного пользователя компьютера и не может быть перемещена на новую машину.
Папка Roaming хранит определенные пользовательские файлы, которые могут быть перенесены с компьютера на компьютер.
Roaming folder is used for User Profile specific data, while the Local folder structure is used for Machine Specific data.
Basically, the user data that you move from XP should be placed in the Roaming folder.
Лучшее объяснение: Local stays with the user on that specific computer. If you are on a domain, a "roaming" profile will be uploaded before you logoff. When you log onto another computer with roaming folders, all of your files in the roaming folder will be at the new computer too.
Эксперимент 1 (файл., стартер, кэш пустой, предприятие)
vrs-cache может создавать и в local (тонкий клиент) и в roaming (толстый клиент)
Value | Count |
---|---|
Local\1C\1cv8\1cv8u.pfl | 6 |
Local\1C\1cv8\_id_\Config\RuntimeCacheStorage | 232366 |
Local\1C\1cv8\_id_\Config\RuntimeCacheVersions | 1055 |
Local\1C\_id_\DBNameCache\cacheData | 3 |
Local\1C\1cv8\_id_\DBNameCache\cacheStorage | 140 |
Local\1C\1cv8\_id_\SICache\cacheData | 30 |
Local\1C\1cv8\_id_\SICache\cacheStorage | 1289 |
Roaming\1C\1CEStart\1CEStart.cfg | 44 |
Roaming\1C\1CEStart\ibases.v8i | 23 |
Roaming\1C\1cv8\1cv8.pfl | 6 |
Roaming\1C\1cv8\1cv8strt.pfl | 12 |
Roaming\1C\1cv8\_id_\1cv8.pfl | 6 |
Roaming\1C\1cv8\_id_\_id2_\vrs-cache\cache.1CD | 44 |
Roaming\1C\1cv8\_id_\vrs-cache\cache.1CD | 44 |
Эксперимент 2 (файл., стартер, кэш полный, предприятие)
Эксперимент 3 (файл., стартер, кэш пустой, конфигуратор)
Value | Count |
---|---|
Local\1C\1cv8\1cv8u.pfl | 6 |
Local\1C\id\Config\ConfigCacheStorage | 17914 |
Local\1C\1cv8\id\Config\ConfigCacheVersions | 7 |
Local\1C\1cv8\id\DBNameCache\cacheData | 3 |
Local\1C\1cv8\id\DBNameCache\cacheStorage | 140 |
Local\1C\1cv8\id\SICache\cacheData | 9 |
Local\1C\1cv8\id\SICache\cacheStorage | 420 |
Roaming\1C\1CEStart\1CEStart.cfg | 20 |
Roaming\1C\1CEStart\ibases.v8i | 13 |
Roaming\1C\1cv8\1cv8.pfl | 6 |
Roaming\1C\1cv8\1cv8cmn.pfl | 11 |
Roaming\1C\1cv8\1cv8strt.pfl | 3 |
Roaming\1C\1cv8\id\1cv8.pfl | 6 |
Эксперимент 4 (файл., стартер, кэш полный, конфигуратор)
Эксперимент 5 (файл., стартер, внешнее подключение)
Кэша изначально нет. Никуда не пишет.
Value | Count |
---|---|
C:\Users\Пользователь\AppData\Roaming\1C\1CEStart\1CEStart.cfg | 4 |
Если создать кэш через запуск предприятия, то . внешнему соединению на него тоже пофиг.
Эксперимент 6 (файл., стартер, пакетный режим - тестирование)
Эксперимент 7 (файл., стартер, пакетный режим - обновление)
Local\1C\id\Config\ConfigCacheStorage
Local\1C\1cv8\id\Config\ConfigCacheVersions
Local\1C\1cv8\id\ConfigSave\ConfigCacheStorage
Local\1C\1cv8\id\ConfigSave\ConfigCacheVersions
Local\1C\1cv8\id\DBNameCache\cacheData
Local\1C\id\DBNameCache\cacheStorage
Local\1C\1cv8\id\SICache\cacheData
Local\1C\1cv8\id\SICache\cacheStorage
Roaming\1C\1cv8\id\*.pfl
Roaming\1C\1cv8\id\id2\*.pfl
Roaming\1C\1cv8\id\*.bin
Value | Count |
---|---|
Local\1C\1cv8\1cv8u.pfl_ | 6 |
Local\1C\id\Config\ConfigCacheStorage | 688460 |
Local\1C\1cv8\id\Config\ConfigCacheVersions | 813 |
Local\1C\1cv8\id\ConfigSave\ConfigCacheStorage | 18958 |
Local\1C\1cv8\id\ConfigSave\ConfigCacheVersions | 3 |
Local\1C\1cv8\id\DBNameCache\cacheData | 6 |
Local\1C\id\DBNameCache\cacheStorage | 244 |
Local\1C\1cv8\id\SICache\cacheData | 31 |
Local\1C\1cv8\id\SICache\cacheStorage | 2002 |
Roaming\1C\1CEStart\ibases.v8i | 4 |
Roaming\1C\1cv8\1cv8.pfl_ | 12 |
Roaming\1C\1cv8\1cv8cmn.pfl_ | 16 |
Roaming\1C\1cv8\1cv8strt.pfl_ | 6 |
Roaming\1C\1cv8\id\1cv8.pfl_ | 6 |
Roaming\1C\1cv8\id\id2\1cv8.pfl_ | 6 |
Roaming\1C\1cv8\id\userDocs_ru.bin.cmp | 1 |
Roaming\1C\1cv8\id\userDocs_ru.new.cmp | 1 |
Roaming\1C\1cv8\id\userPostings_ru.bin.cmp | 1 |
Roaming\1C\1cv8\id\userPostings_ru.new.cmp | 1 |
Roaming\1C\1cv8\id\userVocabulary_ru.bin.cmp | 1 |
Roaming\1C\1cv8\id\userVocabulary_ru.new.cmp | 1 |
Value | Count |
---|---|
Local\1C\1cv8\1cv8u.pfl | 13 |
Local\1C\1cv8\id\Config\ConfigCacheStorage | 205313 |
Local\1C\1cv8\id\Config\ConfigCacheVersions | 530 |
Local\1C\1cv8\id\ConfigSave\ConfigCacheStorage | 1215 |
Local\1C\1cv8\id\ConfigSave\ConfigCacheVersions | 13 |
Local\1C\1cv8\id\DBNameCache\cacheData | 7 |
Local\1C\1cv8\id\DBNameCache\cacheStorage | 305 |
Local\1C\1cv8\id\SICache\cacheData | 28 |
Local\1C\1cv8\id\SICache\cacheStorage | 2394 |
Roaming\1C\1CEStart\1CEStart.cfg | 41 |
Roaming\1C\1CEStart\ibases.v8i | 21 |
Roaming\1C\1cv8\1cv8.pfl | 13 |
Roaming\1C\1cv8\1cv8cmn.pfl | 21 |
Roaming\1C\1cv8\1cv8strt.pfl | 13 |
Roaming\1C\1cv8\id\1cv8.pfl | 6 |
Roaming\1C\1cv8\id\id2\1cv8.pfl | 6 |
Roaming\1C\1cv8\id\userDocs_ru.bin | 2 |
Возможные конфликты
Если запустить два экземпляра одинаковой базы прописанной в стартере - то они умудряются писать в один и тот же кэш-файл.
Когда работаем с базой без регистрации в стартере - почти все временные файлы создаются в темпе. В кэш пишется только vrs-cache. Да и в этом файле фигня какая-то. Данные по хешам и урлам хранятся, поэтому возможно использование одного и тот же кэша разными базами ничего не нарушает. Насколько я понимаю проблема может возникнуть только если этот кэш-файл будут использовать две базы, у которых есть ресурсы с одинаковыми урлами и при этом с одинаковыми хешами при разном содержимом.
Если же база с непустым идентификатором, то в vrs-cache пишутся, например, содержимое запрошенных модулей.
Есть мнение, что второй идентификатор - это идентификатор пользователя базы данных. Так и есть. Для разных пользователей внутри базы он разный!
Если мы знаем ненулевой идентификатор базы, то пустой идентификатор точно трогать не стоит.
Выводы
В каталогах DBNameCache, ConfigSave, Config, SICache хранится множество файлов, кэширующих различные компоненты конфигурации. Эта информация является производной от конфигурации информационной базы, хранимой в базе данных, и служит для ускорения запуска клиентских приложений и повышения их производительности.
1. Чистить кэш нужно только после обновления.
2. Чистить кэш нужно и в Local и в Roaming, причём с одинаковым алгоритмом поиска соотв. файлов и папок.
3. Перед тем как что-то удалять - проверить доступны ли все файлы для удаления, чтобы исключить неконсистентность (база может быть занята).
4. *.pfl файлы не трогать при автоматической чистке кэша после обновления.
Чистить на автомате следующие объекты:
- Папку 1C\1cv8\_id_\Config
- Папку 1C\1cv8\_id_\ConfigSave
- Папку 1C\1cv8\_id_\DBNameCache
- Папку 1C\1cv8\_id_\SICache
- Папку 1C\1cv8\_id_\vrs-cache
- Папку 1C\1cv8\_id_\_id2_\vrs-cache
Уже при ручной очистки предоставить право "грубой очистки":
Поправки для обновлятора
Быстро без кэша загружается только тогда, когда база уже читалась до этого и полностью сидит в оперативной памяти (то есть при повторном открытии читается ОС не с диска, а с оперативной памяти).
Все эти нюансы учтены при разработке программы для администрирования баз Обновлятор-1С.
Если база находится на удаленном компьютере, попробуйте перепрописать путь к ней, скорее всего удаленный компьютер запросит логин и пароль.
Если же каталог с базой находится на локальном компьютере, то проверьте, имеется ли у данного пользователя права на доступ к нему.
При подключении к базе в версий 1С, иногда возникает ошибка доступа к файлу 1Cv8.cdn. Причин этой ошибки несколько.
Первая, она же самая распространенная — база 1С расположена не на отдельном сервере, а на одном из компьютеров локальной сети. Естественно, никакого ДНС-сервера на нем нет, права на папку с базой могут слетать при обыкновенном обновлении Windows — поэтому и теряется сетевой доступ к базе данных.
Остальные причины можно объединить в одну — проблемы с сетью на уровне роутеров, коннекторов, настройки антивируса и брандмауэра, блокирующие сетевые подключения.
Для устранения этой ошибки первым делом надо проверить все сетевые соединения и сетевое оборудование, затем права на папку с базой 1C, сетевые настройки компьютера, настройки антивируса и брандмауэра.
Если проблема будет возникать снова, стоит попробовать установить на компьютер с базой ДНС-сервер стороннего производителя, например Posadis DNS server и настроить его. Затем на других компьютерах локальной сети прописать статичные ip-адреса, а как основной ДНС-сервер указать свежеустановленный, если сеть управляются шлюзом или роутером со своим ДНС-сервером — прописать его адрес в качестве альтернативного.
Ну а на будущее спланировать размещение своей базы 1С на серверной операционной системе, на таких ОС этой ошибки при правильных настройках сети не возникает. Даже необязательно покупать сервер — можно разместить базу 1С в облачном хранилище.
Возникает следующая ошибка с текстом: «Ошибка при выполнении файловой операции RuntimeCacheVersions»
Почистить кэш в appdata, перенести файл базы в чистую папку, почистил temp, из списка соответственно тоже удалить и добавить обратно. Выполнить chdbfl ошибок не показал.
В итоге с 12 платформы открылся документ, а более поздние это 13 и 14 они 64 бита, винда 7, может быть как то с этим связано.
Читайте также: