При свертке DBF файл 1SBKTTL доходит до предельного размера #512468

Добрый день! Имеется DBF-база Бухгалтерии 7.7, которую необходимо свернуть. Перед сверткой файл 1SBKTTL.dbf весит 1.7 Гб. Во время свертки он доходит до предельного размера в 2 Гб, выдает ошибку с кодом -70, и вылетает. Попытка перед сверткой пересчитать итоги приводит к тому же самому. Есть ли какие-то способы решения этой проблемы?

есть.

Не поделитесь ли?

1. либо заплатка от hogik 2. либо создание операций по вводу остатков + отключить проводки, прибитие файла итогов, свертка, + перепроведения операций ввода останков. 3. либо переход  на альтернативные бд - кодебайс, адвантадже 4. либо переход на скуль 5. еще варианты.. ЗЫ: самое простое - 1.

+3 забыл самое главное 6.Исправление алгоритмов базы, чтоб счета закрывались по аналитике, ибо файло итогов не может быть больше файлов проводок по-определению

, алгоритмы типовые, там просто реально огромные итоги по сравнению с оборотами.

стыдно, но первый раз слышу про заплатку от hogik... Где можно про это почитать?

так не бывает. У вас незакрытая аналитика на счетах болтается - куча незакрытых договоров и т.д..

+7 например, приходуете по одному договору, расходуете - по другому. и т.д..

бывает, к сожалению: организация ведет учет бланков строгой отчетности "поштучно", в конце прошлого года был огромный приход в 200 с чем-то тысяч штук. Это все, соответственно, отдельные строки итогов. А на предмет незакрытой аналитики уже проверяли...

ну и что ? И при таком файле итогов, файл проводок какого размера ? Итоги, если что, в разврезе кварталов хранятся, нулевые в следующий квартал не летят, табличка итогов должна быть в разы меньше таблички проводок.

но они же не нулевые! Они еще не списались, висят на остатках из квартала в квартал! С чего бы табличке итогово становиться меньше?

ясен пень - у вас незакрытая аналитика на счетах..

+12 как с чего ? Был приход с клиентоса 100 рублей в 1 квартале - в итогах за первый квартал 100 рублей. Сделали расход на 100 рублей в 1 квартале - в итогах за первый квартал - 0. Открыли следующий период - в итогах во втором квартале записи по этому клиентосу нет. Это как должно быть. А у вас так: сделали приход по Клиентосу по договору 1 на 100 рублей - в итогах запись + 100 клиентос,договор1 сделали расход по клиентосу на 100 рублей по договору 2 в итогах запись  минус 100 клиентос,договор2 открыли следующий период - эти 2 записи попали в начало 2-го квартала. Итого: по клиентосу в целом - 0 сальдо, в разрезе договоров - по одному +100, по другому -100.. В следующий период опять полетят эти записи и т.д.. Итого - табличка итогов пухнет как на дрожжах.

+13 это для примера, а у вас - всё что угодно может быть. И еще раз - табличка итогов всегда в разы меньше таблички движений по-определению, для нормально закрывающихся счетов. Размер 1SENTRY какой сейчас ?

Да нет же! Сделали приход по клиенту 100 рублей и до сих пор, блин, НЕ БЫЛО расхода! он вполне обоснованно там висит! И на начало второго квартала. И на начало третьего. А так как на конец прошлого года был ОГРОМНЫЙ приход, который еще не списан, то никак не обязана табличка итогов быть меньше. Могла бы, но не стала. И чего вы подняли тему о том, ПОЧЕМУ файл итого такой здоровый, если речь идет о том, КАК ее теперь свернуть! з.ы. Если очень интересно, то табличка движений где-то 1,2 Гб.

как свернуть - в всё написано.

страхование ?

Аттракцион невиданной жадности: Есть база бух аж на 2 гига ... оборот оффигенный, но вот СКУЛЬ жмёмся купить... а бабло считать как то надо!

я бы тоже не стал переходить на такой детской базе, у нас ужо 16,4 гига  и ничего..

Как-то тоже попал. Почесал репу и придумал экслюзив. Здесь уже выкладывал.

Поясни разграмотный - ПУБ стандартный. база с 09 года. три раза в неделю клиент шлепает документы на 60контров: заявка, план, выпуск, реализация, сф. База проапдейченная по последний релиз. размер таблиц итогов >1.5 гига. ворочается очень туго. КАК поправить ?

1. Дата начала работы в базе? 2. Дата свёртки? ДБФ?

да

Или скуль или обрезание. Срочно.

Крещение точно не поможет? :-)

Похмелился уже?

Ты первый предложил обрезание...

Свёртка длительнее и мучительнее. Представляешь - крутить пока не оторвётся. Ужас!

Проблемы роста итогов возникают, если БухИтоги используют для аналитики. Например, мы пишем на какой-то счёт все операции клиента - просто для того, чтобы знать оборот по этому клиенту за любой период. В итоги, число клиентов растёт и растёт и файл итогов, так как "умная" 1С хранит все итоги за все периоды в одном файле (и не только 1С так делает). Если итоги по клиенту не нужны каждый раз "мгновенно", а именно мгновенно 1С может показать итоги по счёту на какую-то дату, то можно вместо субконто использовать параметр проводки и делать выборку вручную (обороты по итогам). А если более строго говорить, то итоги - они и в Африке итоги - мы же со счетами работаем - если же хочется какой-то аналитики, то для этого придуманы регистры - там каждый регистр в своих файлах и как бы мы не старались - так быстро 2 Гб не пройти.

Запросто - при незакрытом регистре с десятком измерений.

у него бухитоги. Формально - другое. фактически - тот же регшистр, только периодичность квартал

В том то и дело. Много регистров взамен плана счетов не решает проблему быстрого роста таблиц итогов. У меня при 1SBKTTL.DBF = 300 м, одна из RG > 600. Авторы напихали туда 11 измерений и 7 ресурсов. Вообще к типовой бухии прикручивать регистры - зло.

Типовую должны были эти "типы из 1С" нормально писать, чтобы не садилась в лужу на первом же большом файле. А если в БухИтоги 11 субконто сделать - думаю, что помрёт ещё на старте. P.S. если бы каждый квартал жил бы в отдельном файле, то никакие свёртки и танцы с бубном были бы не нужны.

Жду автора, дабы поделится изящным решением проблемы.

тем не менее, оперативная подсистема ввиду более строгой типизации, и более коротких периодов хранения - удобнее, особенно на прямых запросах. Работать с премлемой скоростью реально большие бухтаблицы (типа размером комплексной 107Г, уж не знаю сколько там проводки и итоги) мне не удалось, да и мало кому удалось...

Оставим пока прямые запросы в стороне. В конфе, срочную замену которой сейчас пишу, бухитоги пересчитываются минут 20, оперитоги 10 часов. Та что от регистров я наверное откажусь.

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

во-первых, можно сделать и так, что оперитоги будут 100 часов пересчитываться. во-вторых, почему "оставим прямые запросы"? например, у меня прямыми запросами происходят регламентно (т.е. по расписанию) 1) контроль оперитогов. 2) при необходимости - выборочный пересчет оперитогов. 3) "восстановление" партионного учета - т.е. грубо говоря, восстановление последовательности по партиям до текущей даты 4) ежемесячная "подрезка" базы до 37 месяцев. Все это не выгоняя юзверей и не создавая запредельной нагрузки. Методами ЖКК такого не добиться

Конфа учёта производства, там партионный учёт нахрен не сдался.

Глянь пост 19 в

в производстве, особенно в многопередельном - партионный учет нужен

Что там надо по лифо-фифо считать?

нафея? РАУЗ вполне покатит :-)

Что это?

это то, что позволяет уйти от партий в производстве...