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

есть.

(1) Не поделитесь ли?

(2)

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

ЗЫ: самое простое - 1.

+3 забыл самое главное

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

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

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

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

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

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

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

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

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

+12
как с чего ?

Был приход с клиентоса 100 рублей в 1 квартале - в итогах за первый квартал 100 рублей.

Сделали расход на 100 рублей в 1 квартале - в итогах за первый квартал - 0.
Открыли следующий период - в итогах во втором квартале записи по этому клиентосу нет.

Это как должно быть.
А у вас так:
сделали приход по Клиентосу по договору 1 на 100 рублей - в итогах запись + 100 клиентос,договор1

сделали расход по клиентосу на 100 рублей по договору 2
в итогах запись  минус 100 клиентос,договор2

открыли следующий период - эти 2 записи попали в начало 2-го квартала.

Итого: по клиентосу в целом - 0 сальдо, в разрезе договоров - по одному +100, по другому -100..
В следующий период опять полетят эти записи и т.д..

Итого - табличка итогов пухнет как на дрожжах.

+13 это для примера, а у вас - всё что угодно может быть.

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

Размер 1SENTRY какой сейчас ?

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

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

(6)
http://infostart.ru/public/15577/

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

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

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

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

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

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

(22) ДБФ?

(23) да

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

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

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

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

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

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

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

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

(32) В том то и дело. Много регистров взамен плана счетов не решает проблему быстрого роста таблиц итогов.

У меня при 1SBKTTL.DBF = 300 м, одна из RG > 600.
Авторы напихали туда 11 измерений и 7 ресурсов.

Вообще к типовой бухии прикручивать регистры - зло.

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

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

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

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

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

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

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

(39) Глянь пост 19 в OLE на конкретной тачке

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

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

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

(44) Что это?

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