(2) andrewks,
В копии быза были сделаны изменения. Добавлен новый регист и в двух документах добавлено движение по этому регистру. Теперь при объединении конфигураций и обновлении информационной базы выдается сообщение.
(4) andrewks,
релиз платформы одинаковый. в данный момент пробую обновить с другого компа, появилось предположение, что возможно это из-за ограничения оперативки.
(6) 2791, и всё-таки, какой релиз платформы используется? попробуйте на 8.2.16, если ниже. и ещё, в сети советуют очистить таблицу изменений
ПланыОбмена.УстановитьГлавныйУзел("00");
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
http://nastroy-ka.ru/system1c/128-qsdbl-q-.html
Тут еще веселее. Получил конфу в коробке от раруса. При загрузке демки на сервер выползает выше указанная ошибка. Спецы раруса навязывают выезд своего на исследование. Причем загрузка в файловую версию проходит гладко и без запинок.
1. Движок везде одинаковый (версионность).
2. Лечение файловой версии и повторная попытка загрузки "вылеченной" версии привело к выше указанному результату.
3. На тонком клиенте, в файловой версии и пустом пользовательском интерфейсе, при попытке открыть список регламентных заданий приводит к той же ошибке. Настроил пользовательский вид до уровня "с картинками и меню", список заданий стал открываться. На радостях попробовал загрузить в серверную версию - фигвам. (
Начал вспоминать что случилось ...
до применения изменений не смог выгрузить базу из конфигуратора , писало ошибку разделенного доступа , хотя в базе не было никого и в сеансах в 1С консоли тоже чисто было. Сделал бэкап SQL и пошел применять изменения ... вылезла ошибка ...
Перезапустил 1С сервер и помогла Выгрузка / загрузка (даже не с примененной конфигурацией)- благо база 1,5 Гб.
Ну скорее всего сеанс на сервере какой-то остался на момент применения изменений ...
в распределенной базе такая ошибка часто может возникать когда изменяются типы реквизитов или "иерархичность"
от такой ошибки можно попробовать избавиться удалением регистрации изменений (предварительно сделав нужные обмены)
когда много планов обмена, то может понадобиться обработка с кодом:
для каждого план из Метаданные.ПланыОбмена цикл
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Планы.Ссылка как Узел
|ИЗ
| ПланОбмена."+план.Имя+" КАК Планы";
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
узел = ВыборкаДетальныеЗаписи.Узел;
если узел = ПланыОбмена[план.Имя].ЭтотУзел() тогда
Продолжить;
КонецЕсли;
ПланыОбмена.УдалитьРегистрациюИзменений(узел, Неопределено);
КонецЦикла;
КонецЦикла;
Если и это не помогает то очистить таблицу регистрации изменений на уровне sql:
use Имя_Базы
delete from dbo._ConfigChngR
delete from dbo._ConfigChngR_ExtProps
последний вариант у меня помогло на платформе 1С:Предприятие 8.3 (8.3.5.1119)
Была такая проблема на БП 3.0(файловая)
1. В базе были изменения структуры;
2. Присутствовала периферийная база.
У меня ошибка возникала в момент обновления конфигурации БД.
Пробовал все перечисленные методы не помогло.
Решалось только закрытием конфигурации перед обновлением конфигурации базы данных
Закрываю конфигурацию- закрываю конфигуратор - открываю конфигуратор конфугурация открыта! База серверная . Возможно нужно чистить кэш на сервере. Просто закрытие конфигурации не помогает.
Помогла очистка таблиц на скуле! спасибо
"use Имя_Базы
delete from dbo._ConfigChngR
delete from dbo._ConfigChngR_ExtProps"
(27) premier, сервера на Винде? что говорит первое правило админа Винды - если ничего не помогает - перезагрузите сервер....
вообще-то, в БОЛЬШИНСТВЕ вопросов помогает перезапуск ключевых служб! Агент 1С, агент Сиквелла, сам Сиквелл
Файловая база. База была РИБ, стала не РИБ. После обработки по очистки планов обмена и Закрытия \ открытия конфигуратора заработало. Что именно помогло - тайна за 7-ю замками.
Обычно такое происходит при сохранении и обновлении конфигураций. Вроде бы все идёт как обычно, но неожиданно компьютер выдаёт: “Ошибка SDBL: Выход за пределы размерности результата”. Хочу сразу сказать, что сложновато найти в Интернете нужную вам информацию по устранению этой ошибки, это может затянуться надолго. Ниже будут представлены все возможные варианты исправления ошибки SDBL
1. Reboot (перезагрузка) сервиса сервера 1С.
2. Тестирование и исправление ИБ.
3. Выгрузка в DT и загрузка его обратно.
4. Установка обновления платформы.
5. Очистить таблицы MSSQL dbo._ConfigChngR и dbo._ConfigChngR_ExtProps.
Первый и третий пункт не всегда дают результат, потому их можно даже не использовать, просто здесь представлены как одни из возможных вариантов.
Также можно попробовать удалить регистрацию изменений, если база Распределенная и имеет подчиненные узлы (РБД).
Пункт первый, т.е перезагрузку можно использовать если база распределенная и имеется несколько планов обмена. Узлы очищаются при помощи обработки: РегистрацияИзмененийДляОбмена83.epf, правда велика вероятность что проблема после этого останется.
Если это не помогло, можно попробовать поставить новую платформу.
Как только все будет готово нажимайте f5 в конфигураторе, конфигурация должна обновиться. Может случиться так что ошибка через некоторое время появится вновь. Тоже делать в этом случае?
Остаётся ещё один способ! Полностью останавливаем все процессы связанные с 1С, а потом запускаем обратно. Конфигурация обновляется, ошибка исчезает.
Далее, после все проделанной операции следует создать текстовый файл, написать туда текст скрипта, и сохранить, поменяв расширение на bat. Запустить файл от имени администратора.
Вылетала такая ошибка перед записью самописного документа. До этого делал проверку базы. MS SQL + УТ сильно измененная. В конфигураторе добавил реквизит к проблемному документу, сохранил - и все заработало. Потом реквизит грохнул.
Танцы с закрытием конфы не помогли (у меня серверная). Помогло только выгрузка в dt, загрузка в файловую и обновление. Потом обратная перегрузка в серверную.
В первый раз помогла очистка регистрации изменений и кэша
Во второй раз и это не помогло, помогла только перезагрузка сервера
1С:Предприятие 8.2 (8.2.19.130)