Есть такая проблема. Есть очень большая база, в которой файлы скоро перейдут порог в 2гб. База никогда ни резалась, ни исправлялась. Потому при попытке, что-то с ней сделать, 1С вылетает с не хваткой памяти.
Сама конфигурация самописная. Стандартная обработка обрезки не работает. А очистку периодических реквизитов проводить нельзя.
Была идея перевести из dbf в sql. Но и там, та же самая проблема. Доходя до загрузки некоторых документов (весьма многочисленных), 1с стремительно набирает память и вылетает. При этом заметил, что в конфигураторе вывелось огромная куча сообщений об ошибках.
Собственно вопрос, можно как-то подавить вывод в конфигураторе этих сообщений?

:))....

болит голова, если ее отрубить то она перстанет болеть?

:) а если остановить деревья то и ветра не будет...

(0) хороший способ подавить - не запускать

(0) что-то мелковато... а если подавить конфигуратор?

Подавление сообщением это не первичная твоя задача, уверяю тебя.

(2) перестанет. Собственно в этом и задача, отрубить кривую голову и поставить по умней

У кого-то есть другие идеи выгрузить, как выгрузить базу из dbf в mssql? Или так же будете продолжать, ваше мастерство в сарказме?

>>> в которой файлы скоро перейдут порог в 2гб
ну и какой самый большой файл у тебя и как его имя ?

Один из способов лечить дбф базу выгрузить и затем загрузить. Тестирование надо полагать не помогает. Тогда формировать остатки и начинать новую.

блин 86.
:(

(8) :) тут или 0 запятых или 2...если это титул...

(11) :)))) "как я сам не дотумкал..."

(8) можно попробовать вылечить ошибки, о которых плачет конфигуратор

(8) :)
зы
лог давай, чучело чернобыльское...

Ну вот, вспугнули.. теперь пойдёт подавлять кого-то еще

(9) 1SENTRY и 1SConst. Но их почистить нет возможности. Я их чистил давно и освободилось совсем мало. Полгода прошло с того момента, хватит еще на месяца 3.

(10) То я и хочу сделать. Но увы из-за большого количества ошибок в бд, конфигуратор вылетает

(16) :) "Служители  взяли
большой мешок, сунули туда свинку вниз головой, завязали  мешок  и  сели  на
него.)
    - Я очень рада, что увидела, как это делается, - подумала Алиса. - А то
я так часто читала в газетах: "Попытки к  сопротивлению  были  подавлены..."
Теперь-то я знаю, что это такое!"

(17) размер то какой у 1SENTRY хоть ?

>>>Потому при попытке, что-то с ней сделать,

подробнее, что делаете ?

(14) увы то о чем он плачет - это еще не все. Что-то еще увидеть у меня не получается. А то что выводил исправлено.

(15)логов нет, ибо то что выведено в окно сообщений, там и остается, а после ошибки, конфигуратор закрывается

2 068 747 737

(21) загрузить/исправить

Да уж..
Тут только одно - ставить заплатку от hogik и либо резать базу, либо кидать в скуль.

Чтоб кидать в скуль, нужно как минимум, привести общие реквизиты в порядок + проверить журнальчик и файло проводок на пустые даты.

(10) сформировать остатки и начать новую не получится. В остатках отражено далеко не все, что нужно

(26) что за заплатка?

(26) Как привести в порядок, общие реквизиты, журнал и файл проводок?

http://infostart.ru/public/15577/

+общие реквизиты с типом строка неогр длины должны быть последними в дереве метаданных.

запросом или ручонками проверить 1sjourn и 1sentry на наличие пустых дат, ну и 1soper еще

(3) меня смущает вот это строка

А так как существует уже другое ограничение на размер DBFов в 2GB, то в 4GB никакая реальная запись не попадёт.

Что это значит?

(32): это значит, что поскольку существует уже другое ограничение на размер DBFов в 2GB, то в 4GB никакая реальная запись не попадёт.

(33) не тупи. Я это понимаю так, что после 2х гигабат записывать в файл ничего не будет.

Подавить с приоритетом из НЕвыгружаемой конфигурации..

?

(34): это не я туплю.

в общем возьму на вооружение дополнение hogik. А пока буду пытаться полечить 1sjourn, 1sentry и 1soper

(37) :) он видимо писал (*32)

а написать свою обрезку слабО? в чём проблема то?

остатки по счетам получить туго? потом лепишь пустую базу со справочниками и заливаешь остатки через операцию. мне на нестандартную бухию понадобилось день чтобы написать обрезку не "на сейчас" а на любую дату

При выгрузке получил ошибки про неверную нумерацию строк документов. Связано это с тем, что ограничение по длине номера строки (4). А в документе их больше 10000. В итоге получается куча строк с номером 0. Кто-нибудь знает как это исправить?

Делить документы.  можно руками(если документов мало), можно обработкой.

(42) вот и добрались до баяна...

только резать, не дожидаясь перетанита....

зы
скорее всего это документы ввода остатков, тебе их порубать примерно по 5000 строк нужно...

зызы
про бекапы не забывай

(44) в семерке ограничение в 9999 строк в одном документе (создать больше можно, но они не привязываются к проводкам)

Это не ввод начальных остатков а выгрузка реестров абонентов. Буду пробовать делить их

а чего пробовать то? Копируешь документ и лишние строки удаляешь таким образом что бы в каждом документе строки были разные. Это если руками, если обработкой то и того проще, считываешь документ грузишь все в ТЗ, затем очищаешь табличную часть и заполняешь 9999 строк в первом, затем создаешь новый и вываливаешь строки, если надо то и 3 док делаешь.  На будущее загрузку делаешь с учетом ограничения в 9999 строк.

(27) Те, кому нужен архив могут заглянуть в больную базу. В остальном будут работать в новой и подлеченной. Зря отвергаешь открытие новой базы. Когда рухнет, то ни одной базы не будет.

не поучений, токмо инфы для..
у нас в конфе есть обработка, называется "Завершение периода".. С названием - не ко мне, а к программисту, кторый её писал лет 10 назад.. Так я его и не увидел ни разу :)
(а вот с содержимым - это как раз ко мне :) )

Так вот, она обрезает базу, перенося все остатки по регистрам в спецсозданные документы, 4 штуки, ну, и часть документов, на которые есть ссылки.

делаем обрезание каждые 2 года. На моем веку - дважды.
В документы по остаткам пишем не более 100 строк, чтобы были обозримыми.
вот как-то так..

+49 естественно, старая остается для инфы.
да мало кто туда заглядывает..

Да проблема то в том, что я не знаю этой базы. Обрезать то не проблема. Но как она себя будет потом вести, понятия не имею. Конечно, можно провести время за её изучением, все сторонним тестированием и пр. Но база это далекого отделения, связь с которым через телефон и узкий vpn.
А занимаюсь я этой базой между делом (переходом на 8.2 и поддержкой текущей основной базы 7.7).

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

Проблема в том, что я не уверен, что она доживет до самого этого момента. И хочу с наименьшими трудозатрами продлить жизнь пациента.

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

(0)Переводи на SQL и отдыхай.
А по сути у вас походу операции не закрываются, т.е. даже при свертки у вас мало место освобождается, все на счетах висит (на остатках) :)

(51) Вам предлагают не изучить конфу, а исправить ошибки документа, у которого больше 9999 строк, путем разбивки его на части, содержащие не больше 9999 строк. Судя по всему таких доков много. Их нужно разбить на части. Для этого не надо знать базу. Нужна обработка, которая переберет доки и порежет их на мелкие части. :)

(52) Это я пытался сделать, если почитаете первый пост
(53) Написал уже подобную обработку.