1с расширение ошибка получения информации набора данных
Обновлено: 04.07.2024
С появлением режима совместимости 8.3.12, как вы знаете, появилась возможность распространять расширения из центрального узла в подчиненные вместе с обменом. Будем считать, что план обмена и конфигурация у вас поддерживает передачу расширений в узлы (подробнее по настройке вы можете посмотреть, например, тут).
Казалось бы, после этого достаточно просто добавить расширение в центральный узел, установить ему признак "Используется в РИБ", выполнить обмен и принять расширение в узле! Но реальность оказалась куда "интереснее".
Идентификаторы объектов расширений
Первая проблема, с которой вы можете столкнуться в центральном узле (при использовании типовой конфигурации) при выгрузке - это возможное отсутствие записей в справочнике "Идентификаторы объектов расширений", если в расширение вы добавили новые объекты (справочники, регистры сведений и т.д.). В этом случае можно выполнить обновление справочника процедурой:
К статье прикрепил готовую обработку с одной кнопкой, которая запускает выполнение этой процедуры:
Нарушение прав доступа, файл не обнаружен Params\DBNames.
Еще одна проблема, которая может изрядно испугать рядового пользователя. Не всегда, но возникает после подключения расширения, в котором добавлены новые объекты. Пользователи даже с полным правами не могут войти в 1С, хотя вы уверены, что на свои объекты вы дали права, либо чтение/запись производится в привилегированном режиме. И вообще, почему он ругается на таблицу, явно связанную с новым добавленным объектом? При этом утилита chdbfl проблем не обнаружила, да и ТиИ результатов не дало. И вот тут стоит вспомнить шутку о том, что
В любой непонятной ситуации - чисти кэш!
Да, это именно тот случай: чистим кэш и прощаемся с проблемой!
Ошибка получения данных в узле (файловая база)
Итак, расширение в центре подключили, сделали выгрузку: осталось получить данные в узле! Да проще простого! Запускаем обмен и видим следующую картину:
Ага, думаем, расширение пришло и 1С просит перезапустить сеанс! Но после перезапуска расширение не работает, а обмен так и не идет. Ладно, смотрим ЖР:
Как так? Сеанс всего один и именно из него мы пытаемся выполнить обмен! Как еще можно это сделать? Ок, дождемся запуска обмена по расписанию. Ничего не поменялось?! Ну тогда чистим кэш, делаем тестирование. Ошибок при тестировании никаких, кэш почистили, но обмен так и не идет! После чтения ИТС, списка изменений в релизах платформ, экспериментов выяснилось, что все дело в платформе! После перебора версий выяснилось, что ошибка точно присутствует в версиях 8.3.13.1690 и 8.3.14.1565, а на версии 8.3.13.1513 обмен проходит без проблем. При этом, если на узле используется клиент-серверный вариант работы, то ошибка не воспроизводится. Опять-таки, в ходе экспериментов выяснилось: первый обмен следует запускать кнопкой "Выполнить сценарий" в форме настройки сценариев обмена; причем обмен удивительным образом проходит даже на проблемных версиях платформы! Почему таким образом удается провести обмен - пока непонятно. Стоит отметить, что в центре можно использовать любую платформу: ошибок с обменом в центральном узле не обнаружили.
Напоследок
Как выяснилось позже, если у расширения стоит признак "Используется в РИБ", то оно попадает в файл обмена при каждой выгрузке! Да, даже если вы не вносили изменений в расширение, оно все равно будет каждый раз выгружаться в узел! Так что если у вас проблемы с интернетом на точках, то самое время заняться оптимизацией состава расширения!
Следует помнить: если вы добавили новые объекты в расширении, у вас настроен РИБ через план обмена, который поддерживает передачу расширений в узлы, то обмен у вас не заработает до тех пор, пока вы у расширения не поставите признак "Используется в РИБ"!
А если вы еще не перешли на режим совместимости 8.3.12+?
Надеюсь, данная статья поможет вам сэкономить массу времени нервов! Буду рад дополнить статью также вашими замечаниями, инструкциями и "находками" по данной теме!
Тестирование выполнялось на конфигурации 1С:Розница 2.2.11.29 и платформах 8.3.13.153, 8.3.13.1690 и 8.3.14.1565
РИБ и расширения: обновление идентификаторов метаданныхСпециальные предложения
Имеется в виду ссылочные объекты?
У меня в расширении есть добавленные объекты (формы), признак использования РИБ отключен, синхронизация выполняется. Расширения в узлах обновляю вручную.
Что касается полной передачи расширения в РИБ, это и ожидалось, там просто иного не предусмотрено, ровно как и в моём решении
Ну можно же было сделать проверку по контрольной сумме: поменялась - выгружаем. Думаю, это дело времени (5)А от куда главная база узнает контрольную сумму? Хотя конечно можно было сделать, как я предлагал в своей статье, это при выгрузке в центральную базу, добавлять хеш-сумму расширение, а от неё бы уже центральная база проверяла и узнавала, надо менять расширение или нет. Но 1Сники видимо решили по проще сделать. при выгрузке в центральную базу, добавлять хеш-сумму расширение
1С вроде сейчас так и делает. К сожалению, сейчас нет РИБ под рукой, но в XML был узел с именем "DigestExtension" или как-то так (7) Тогда странно что каждый раз выгружает. В моём кстати решении, там на сервер передается хеш сумма расширения и сервер тем самым узнает что надо передавать расширение клиенту или нет. Но вот разностная выгрузка средствами языка к сожалению не возможна. (8) да с разностной выгрузкой ладно, в большинстве случаев расширение не так много весит. Надо будет повнимательней последить за хэшем расширения в файле обмена. (9) Я как то анализировал эти хеши. Была ситуация, когда хеш расширения в центральной базе не совпадал с хешем расширения в периферийной базе. Это получилось из-за того, что некий узел конфигурации-расширения из центральной базы не передавался в периферийную. Возможно этот узел использовался в предыдущих версиях платформы, а в новой версии про него забыли и он просто лежит там как мусор. Если взять расширение из периферийной базы и загрузить в центральную, то хеши расширений начинают совпадать. Я надеялся, что после совпадения хешей расширение конфигурации перестанет каждый раз передаваться в периферийную базу, но оно всё равно передаётся. Ну хоть работает, уже хорошо. Большое вам человеческое СПАСИБО! Предлагаю сделать свой bugboard платформы 1С на инфостарте. Каждое обновление платформы как игра в рулетку или взлетит или нет( (13) зачем плодить сущности?
От этого будут быстрее ошибки исправлять?
Ставлю признак "Используется в РИБ", при попытке обмена ошибка в ЦУ:
Что с это значит?
(16) Похоже, что загрузили расширение в пользовательском режиме, но сеанс не перезапустили.(17) Загружал в конфигураторе.
для чистоты: завершил все сеансы - удалил расширение в конфигураторе - перезапустил 1С - добавил расширение в конфигураторе с признаком "Используется в РИБ" - запускаю обмен в режиме предприятия - та же ошибка.
(18) та же история 8.3.13.1690, 8.3.14.1630Работает через кнопку сценарий (19) Через сценарий обмен так же не взлетает
По крайней мере в 8.3.13.1644 . (20) Решилось удалением всех расширений в конфигураторе (установленных до обновления платформы) и добавлением их по новой. Обмен пошел сразу по кнопке Синхронизировать.
Решение подойдет в случае, если в расширениях нет собственных документов и справочников. (21)Платформа 8.3.13.1644
1. Подтверждаю, если в расширении не добавлены объекты из расширяемой конфигурации (или не добавлены новые объекты), то обмен работает по кнопке "Синхронизировать".
2. Подтверждаю, вывод статьи: если в расширении добавлены новые объекты метаданных, тогда первую синхронизацию с Узлами нужно делать по кнопке "Синхр. по сценарию", тогда расширение мигрирует в удаленную базу. После этого перезапускаем базу - чтобы принялись изменения расширения и снова жмем "Синхр. по сценарию" - в этот этап "подхватываются" уже данные. Да, если не перезапустить базу, то можно увидеть, вернее, не увидеть записи для заимственных в расширение объектов. При последующих синхронизаций, лучше синхронизировать "по сценарию", а то, вдруг обновление прилетит. Да и пользователей нужно учить, если синхронизация выполнена с ошибкой, пускай перезапускают базу и снова синхронизируются.
Как-то так.
Всё это ерунда. Пока не исправят баг с платформой счастья в РИБ не ищи. Пляски с бубном помогают каждому по своему. У нас 2 сервера для 1) 8.3.14.1565 пока танцевали с бубном каким то чудесным образом из файлов обмена пропали данные по расширениям. Если раньше есть расширение в ЦБ, то в файле выгрузки идут строки
<v8de:ConfigurationExtension>
<v8de:Id>645b2314-4ade-11e9-8d9e-708bcda98ec4</v8de:Id>
<v8de:Name>ОстаткиИЦеныВПодборе</v8de:Name>
то сейчас их нет. И обмен идёт отлично. Как так получилось но я рад до следующего обновления платформы)
2) 8.3.14.1630 Здесь не помогло не чего. Так и делаем обмен через сценарий.
P.S. пока танцевал с бубоном заметил такую вещь.
Если ЦБ 8.3.14 а ПБ 8.3.13 обмен не идёт не при каких условиях, так как в файле обмена меняются строки
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 v2="57881d97074ef04efe7be54c9c51d7d2" Extensions="0000000000000000000000000000000000000000">9d1874 89ecad40d6c652763c4f4f5ac8</v8de:Digest2>
Где то на форуме многие страдали от этой проблемы. Может кому поможет.
На сайте багборда не нашел соответствующей инфы (25) Да. У меня РИБ на 2х серверах на 8.3.14.1694 взлетел. На данный момент полёт нормальный. Уже даже обновил розницу до 2.2.12.хх
Ошибка на платформе: "8.3.13.1865"
Розница: "2.2.11.24"
Напиши, потом, как дела с этой платформой у Тебя))
Да обновление платформы исправляет ситуацию, спасибо. (30) На 8.3.14.1779 точно осталась только проблема с первоначальной загрузкой расширения (либо при загрузке обновления расширения) - для решения см. пункт "Ошибка получения данных в узле" (31) расширение передаешь из центральной базы в переферийные? (32) да. При первой передаче или при изменениях расширения в центре - в узле изменения приходится принимать через кнопку "выполнить сценарий"; потом обмен проходит без проблем (29) Обновил розницу до 2.2.12.30 версия платформы 8.3.13.1865 обмен на узле РИБ возможен только через кнопку "Выполнить сценарий" и когда в базе сидит один пользователь. Как только подключается второй пользователь сразу идет ошибка "База данных заблокирована" Помогает обновление платформы решить данную ошибку? (35) к базе подключаются два пользователя на одном компьютере (36)Платформа 8.3.14.1630, Розница 2.2.13.12, файловая периферийная - та же ерунда. Обмен работает только если вручную нажать "Выполнить сценарий". В центральной все ОК. (37) решил в правилах отключить передачу расширений в РИБ, проверил на тестах - обмен работает (38) Так да, работает без проблем. А если в расширение добавить новые объекты (регистр, справочник и т.п.), то РИБ не будет работать со снятой галкой "Используется в РИБ" у такого расширения (39) а других вариантов пока не вижу, к сожалению не всегда есть возможность сделать обмен что бы на периферийной базе работал один человек. Пока идет обмен, обычно еще и торговать надо. (39) Именно так. Если в расширении есть новые объекты или изменены имеющиеся объекты на уровне данных, то расширение придется включать в обмен, без этого на периферийной базе не будут загружаться пакеты
Описан готовый механизм решения следующей проблемы:
При добавлении ролей в расширение конфигурации 1С 8.3 нет возможности в режиме предприятия корректно назначить их пользователю с полными правами (Администратору). Т.к. отрабатывает стандартный код общего модуля 1С УправлениеДоступомСлужебный процедуры ОбновитьРолиПользователей, который сбрасывает все роли, переназначая основную (ПолныеПрава) и дополнительную (ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок).
А теперь разберем пример на «простом языке».
Была задача создать новые роли в расширении. Режим совместимости конфигурации ниже 8.3.13 (т.е. нет возможности применения «Основные роли» в том числе). При назначении ролей полноправным пользователям выявлена проблема: роли из расширения конфигурации 1С 8.3 недоступны (по вышеуказанной причине).
2. Решение проблемы с ошибкой при расширении конфигурации
Решение можно реализовать как в текущем, так и в отдельном расширении:
1. Добавить в расширение общий модуль УправлениеДоступомСлужебный:
2. Заменить процедуру ОбновитьРолиПользователей
Копировать код 1С:Предприятия из основной конфигурации. Между строк вставить код:
(!) Тут укажите имя своего расширения, которое содержит ваши роли:
3. Подключите (или обновите) расширение.
4. Назначьте эти роли в режиме 1С:Предприятия (Роли – в Профиле, Профиль – в Группе доступа, Группу доступа – полноправному пользователю).
Приветствую, коллеги! В данной статье будет рассмотрена знакомая и набившая оскомину многим специалистам 1С ошибка SDBL, а также возможные пути её устранения.
1. Возникновение ошибки SDBL
· была совершена попытка вставить значение с недопустимым типом;
· был совершён пропуск точки с запятой;
· имеет место ошибка, которая произошла при индексировании с полным текстом;
· некоторое поле имеет неоднозначное определение;
· не хватает выражения (pos =);
· совершён выход из размерностей;
· в поле таблицы используется невозможный тип значения «NULL».
2. Устранение ошибки SDBL в 1С
Устранить ошибку SDBL можно одним из способов, которые описаны ниже.
1. Сделать перезагрузку на сервере с приложениями для 1С 8.3. Далее может помочь, если включить и выключить все сервисы SQL и агентами SQL. Для этого потребуется зайти на сервер, выбрать «Агент сервера 1С» и при помощи контекстного меню приостановить работу. По аналогии сделаем с «Агентом SQL» и «SQL Server» для сервера SQL. Затем следует снова подключить их, но в обратной последовательности.
2. Выгрузить базу с данными в некоторый файл, который будет иметь расширение DT, а затем выгрузить её назад – в ту же базу с информацией. Аналогично будет исполняться для режима конфигуратора при помощи вкладки меню «Администрирование» – посредством использования команд «Загрузить информационную базу…» и «Выгрузить информационную базу…».
4. Также можно обновить платформу на более современную версию (с главного портала – ИТС). Для выполнения данного действия скачиваем с ИТС новую платформу 1С 8.3 и устанавливаем ее на компьютерах клиентов и на сервере.
5. Рассмотрим еще один вариант – использование механизма «Тестирование и исправление информационных баз», который находится внутри конфигуратора. В необходимой базе переходим по пути: «Администрирование → Тестирование и исправление информационных баз», а далее запускаем процесс.
6. Совершим загрузку внутри копии, которая является резервной, если она была создана в недавнем времени. Замечание: обязательно часто делать резервные копии до любого важного действия с ИБ. Копии делаются посредством SQL MS или конфигуратора, при этом происходит выгрузка файла в формат dt.
Если ни один из вышеперечисленных способов не устранил ошибку SDBL, следует произвести очистку таблиц _ConfigChngR_ExtProps и _ConfigChngR. Однако для этого потребуется знания принципов работы MSSQL.
Приветствую, коллеги! В данной статье будет описана ошибка «Ошибка при выполнении файловой операции», и подробно рассмотрены способы ее устранения.
Когда происходит обновление конфигураций в 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 «Ошибка при выполнении файловой операции» больше не возникнет. Спасибо за внимание!
Читайте также: