v7: Большая база ТиС SQL - ошибка "Недостаточно памяти" при сохранении конфы #581818

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

так v8 или v7 ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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