Есть база ТиС SQL 30 гигов.
Есть потребность на один из общих реквизитов документов поставить галочку "Отбор".
При сохранении изменений конфигурации 1Ска долго обрабатывает документы, потом выдаёт ошибку "Недостаточно памяти" и не сохраняет изменения.
Можно ли как-то решить эту проблему без прямого модифицирования SQL базы с подсовыванием MDшника?

так v8 или v7 ?

(1) Ой, запарился, не выбрал версию 1С в посте. 1Cv7

(1) 7ке есть подобная ошибка?

(3) Есть, есть. Именно 7.7.

можно сделать так... сделать изменения на пустой базе. посмотреть какие индексы создает 1С. сделать их ручками в базе. подменить конфу. не уверен, что все учел, но попробовать можно. только копии и бэкапы не забывать сделать.

а нет. гоню. там в журнал добавляется новый реквизит еще... впрочем и это тоже можно сделать. только уже сложнее.

(5)
читайте внимательней условия задачи

в общем направление мысли думаю понятно.

(5) Попробовал. При установке галочки отбор 7ка удаляет этот общий реквизит из таблиц шапок всех документов и добавляет его в общий журнал, создаёт индекс.
Создать реквизиты и индексы легко, а вот заполнить новый реквизит в 1SJourn я запарюсь.

(9) ну а кто сказал, что будет легко. если надо, добавишь. если сам не можешь, заплатишь.

(9) ? тупо update и select из шапки документа

потом alter table - прибьешь колонку в шапке

(10) Ну... Надеялся, что подскажут методу попроще. А то еще неизвестно сколько с базой жить, сколько ей ещё расти и сколько еще подобных проблем "большой" базы вылезет. База еще распределёнка, где-то SQL, где-то DBF. Поэтому хочется более штатными средствами обойтись.

Пока вопрос удаётся решить штатными средствами. Добавил рядом с нужным реквизитом новый сразу с отбором. Добавился. Ночью 1Сными средствами заполню новый реквизит, переименую и попробую грохнуть старый. Надеюсь, на этапе "грохания" ошибки не возникнет. :-)

А обрезать базу не пробовали? Можно ещё сделать упаковку таблиц через тестирование и исправление

(15)

для SQL упаковка таблиц ?

(14) Только попрощайся со всеми полями, где есть ссылки на этот реквизит

(17) ну вот.. испорти завтрашнюю тему - как с архива вернуть усё взад.

(13) Кстати, что самое интересное, проблем в распределенке - не возникает...
Почему - я не понял. похоже, для обновления путем накатывания конфигурации из ЦБ - используется какой-то другой механизм.

(18) Ему бы "в зад" с утра бы уже так "ввернули"...

(17) Почему это? Всё нормально. Заводим навый реквизит. Обработкой из нескольких строк копируем в него значения старого. Удаляем старый, переименовываем новый под старый.
(18) Спасибо за предупреждение, но я к неофитам не отношусь :-) Прямыми запросами владею плохо, это да, пишу их только по большим праздникам, но 200+ гигов 1Сных баз у меня пока живут, ни одна не умирала :-)

(21) Все когда-то происходит в первый раз... :-)))

(22) Типун тебе на язык, брат мой по маразуму! :-)

(0) Попробуй перед тем, как отбор ставить, передвинуть этот общий реквизит в метаданных наверх.
Встречал такие танцы с общими реквизитами при переходе с DBF на SQL версию

(21) ^)) А на ссылочную целостность нас..ть ?

(25) Не пойму я тебя? Ну завел новый общий реквизит рядом с имеющимся. Скопировал по всем документам в базе значение старого общего реквизита в новый. Вся инфа дублируется в двух реквизитах. Удалил старый. Где и что может пропасть? Куда какие ссылки исчезнут?

Нечто подобное наблюдал на dbf базах, решали такие вопросы удаляя из базы большую часть прав, после чего сохранение происходит нормально, и копируя права в рабочую базу из копии обратно