Есть достаточно большая бухгалтерская база v77 SQL 20 Гб. (Континент-Страхование, написанная на основании типовой бухгалтерии)
В отчет попадает около 0,8кк документов, по каждому документу 5-6 бухзапросов по состоянию счета на конец квартала.

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

При работе обработки 1С виснет и выедает всю память. (24 гб оперативки)
Что тут можно сделать?

переписать логику

(1) например?

(2) для начала расскажи входные данные + как должен выглядеть отчёт

>>> на каждый документ создается строка таблицы значений, рассчитывается бухзапрос по субконто

ну еще бы память не выедалась

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

(4) как сделать по-другому?

хочу понять логику автора: а как по вашему должен выглядеть ответ на ваш вопрос, в виде готового отчета?

(7)да, и код с подробными комментами.

там данные все в бухрегистрах? можно при проведении продублировать нужные для отчета данные во внешнюю базу на MSSQL , потом в отчете получать результаты за минуту. Все прелести T-SQL будут у тебя в руках

(9) фия как через одно место то, а без дублирующих таблиц некак?

(7) например, посоветовать как (9).
(9) спасибо, сейчас перепровести базу с 2002 года не представляется возможным.

(5) введи забалансовый счет с аналитикой

(11) в (7) советуют бред
з.ы. в нормальных учетных системах скуль сам считает данные без всяких внешних оболочек типа 1с.

(11) в чем проблема несколько ночей проводить по 1 году

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

и в итоге получим тоже самое, но в двух экземплярах :)

ну или вариант - ускорять 1С77 шаманством - драйвер от FoxPro, прямые запросы и т.д. и т.п.

(16) нет, после проведение всех документов до сегодняшнего дня получившуюся скульную базу прицепляем к рабочей и копию удаляем

+ (12)

сотрудник / случай

(18) что нет? напрямую религия запрещает обращаться к таблицам 1с? зачем дублирующие городить? ответьте на мой ответ!

(18) т.е. получается, в полете не поймать, надо стелить соломку?
(20) как напрямую обращаться? где про это почитать?

по хорошему нужно создать хранимую процедуру на сервере скл и запускать ее из 1с в виде отчета. почитать в интернете.

(17) анакуа, пардон за мой французский, "драйвер от фокспро", если база и так сиквельная?
http://www.1cpp.ru/forum/YaBB.pl?num=1181817217

(22) (23) спасибо, буду изучать

(21) открой для себя 1с++

(25) придеться. и 1с++, и страхование тоже... =) новая предметная область. После производства и торговли много непонятного.

(20) там структуру надо разбирать, а в дублирующих можно по своему таблицы задать, индексы поставить и всякие другие оптимизации сделать
В крайнем случае можно вьюхи по стандартным таблицам написать

Компоненту Toy SQL попробуй, реально работает.

(0)У тебя отчёт по одному полису так тормозит?

(25) сервер скл так быстро считает, что без прокладки-тормоза в виде 1с никак?

(27) в чем проблема разобрать, если есть словарик? бедная 1с, как она сама то разбирается в своей структуре :)

ну если там простые самописные документы то можно и по стандартным таблицам, но все равно стоит сделать какие то доп. таблицы с подготовленными или укрупненными данными для отчетов за прошлые периоды. Это уже пусть (0) разбирается что ему более подходяще будет

(29) подобных отчетов около 20. страховая отчетность

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

(32) - насчет укрупненных расчетов - интересная идея. имхо, для расчета резервов пригодится.

(30) Прокладка - по сути, метапарсер при отправке запроса, и типизатор при приеме результатов запроса (если нужны расшифровки) . Остальное делает сервер. если  запрос будет не динамический, то можно хранить сразу препроцессировный запрос. Если много однотипных подзапросов - можно сохранить построенный запрос как хранимку (и даже подучать отчеты каким-нибудь КристаллРепортом ). тут все зависит от задач.
(32) во-первых, "укрупненные данные за прошлые периоды" 1с и так хранит. во-вторых, можно, конечно, загнать все в куб, и там крутить - но ТС нужны не аналитические отчеты, а "а-ля фискальный".

(33) проще будет создать запросы в 1с++, потом их отловить в скл мониторе, и закопипастить в хранимую процедуру.

я как то читал статью про расчет рисков в страховании. Там даже какой-то особый раздел математики придуман под это, а расчеты оптимизировали с использованием CUDA на видеокартах, обсчет статистики сократился с нескольких часов до 4 минут

(37)Тогда уж легче в Toy SQL, там всё сразу посмотреть можно.

(36) аналитику тоже хочу! так как ее нормальной нет...
(38) я только начал это дело ковырять. про расчет рисков знаю (теорию) - дело за тем, чтобы навести порядок, чтоб фирма нормально работала, потом уже всю статистику разводить и аналитику.

(36) врятли получится обойтись одним запросом, придется использовать временные таблицы, так что 1с++ вариант, но не рациональный. единственное достоинство 1с++ это создавать код запросов в скл виде.

(37) А зачем отлавливать их в мониторе, если есть метод ОбрМетаСКЛ ?
тебе "платят за лишние телодвижения"? :-)))

(42) умный человек 1с++ писал, респект ему за этот метод, не знал.

короче переписывай емкие запросы на хранимках, 1С пусть будет средством ввода данных и показа отчетов. Все расчеты и аналитику пусть считает скуль.
Сколько там памяти на скуль-сервере кстати? Ставь 32 гига и всю базу в память пихай

(41) достоинство - метапарсер (пусть уж железяка сама работает со своими внутренними именами). И отладка "внутри приложения".
впрочем, есть еще построитель запросов, и т.п.

(43) подсистему прямых запросов писал Павел Шемякин, он же автор ToySQL

(45) в любом случае скл сервер без костылей считает быстрее.

(44) Зачем всю базу? есть методы закрепления в памяти отдельных таблиц, нужных для оперативной работы.

(47) согласен. но кроме  собственно расчетов, есть еще передача входных параметров, типизация результатов и т.п. Плюс скорость разработки и отладки.

(40) а аналитику советую делать через http://www.1cpp.ru/forum/YaBB.pl?num=1193394153

(50) крутые средства делают для семерки )) хоть не переходи на восьмерку совсем

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

тоже что ли запросом к таблицам 1С в скуле?

(50) пародия на кристал репортс %)

Оптимизировать, ты то для этого и нанимался, а писать отчеты через мастер может и простая кухарка :)

(54) Не, даже не пародия. Другой инструмент. Но, тем не менее, достаточно  удобный...

(0) "далее таблица значений сворачивается, ведутся дополнительные расчеты, итоги подбиваются"
Итоги "подбивать" можно, обрабатывая ТЗ частями.
Часть обработали, итоги подбили, удалили ненужные строки.

(57) хм. точно.

(57) Да путей решения много. в свое время кто-то писал эмуляцию работы с большими ТЗ через dbf...
в первую очередь надо порядок в голове навести.

(59) в этой конфе очень много работы с внешними dbf в расчетах...

(60) :-)))

(60) Еще из вариантов:
1) Как уже было предложено - не закачивать данные в ТЗ, а складывать во временную таблицу
2) Вместо MSSQL можно воспользоваться, для некоторых целей, SQLite
Например, из моей практики, надо было анализировать движения по регистру в разных ракурсах:
       Состояние("Формируем временную таблицу");
       глРС_Аддон.Выполнить("DROP TABLE #tmp_poteri");
       //Формируем список рассматриваемых товаров
       ТекстЗапроса = "
       |SELECT
       |    $ПартииТоваров.Товар                                            Tovar
       |    , Журнал.DATE_TIME_IDDOC                                        dt_iddoc
       |    , Журнал.IDDOC                                                    iddoc
       |    , ASCII($ПартииТоваров.КодОперации)                            KO
       |    , $ПартииТоваров.Количество*(1-ПартииТоваров.debkred*2)        Количество
       |    , $ПартииТоваров.СуммаРублевая*(1-ПартииТоваров.debkred*2)    Сумма
       |    , $ПартииТоваров.СуммаНДС*(1-ПартииТоваров.debkred*2)            НДС
       |    , $ПартииТоваров.СуммаПродажиРуб*(1-ПартииТоваров.debkred*2)    прСумма
       |    , $ПартииТоваров.СуммаНДСПродажи*(1-ПартииТоваров.debkred*2)    прНДС
       |INTO #tmp_poteri
       |FROM _1SJOURN AS Журнал With (NOLOCK)
       |    INNER JOIN $Регистр.ПартииТоваров AS ПартииТоваров With (NOLOCK) ON Журнал.IDDOC = ПартииТоваров.IDDOC
       |WHERE (Журнал.DATE_TIME_IDDOC between :НачДата AND :КонДата~)";
       
       ТекстЗапроса=ДобавитьФильтр(ТекстЗапроса,ВыбТовар,"Номенклатура","$ПартииТоваров.Товар");
       глРС_Аддон.УстановитьТекстовыйПараметр("НачДата",ДатаНачала);
       глРС_Аддон.УстановитьТекстовыйПараметр("КонДата",ДатаКонца);
       глРС_Аддон.ВыполнитьСкалярный(ТекстЗапроса);
       глРС_Аддон.ВыполнитьСкалярный("CREATE INDEX idx_KO_IDDOC on #tmp_poteri(KO,dt_iddoc)");

(62) забавно, токма нафига sqllite использовать в скулевой базе ?..

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

(63) типа, показать, что умеет... :-)

(63) Повторюсь, для некоторых целей проще через нее. Например, получив обширные данные в ТЗ (в частности, как указал ТС, из внешних dbf-ок), нафига их передавать на сервер? А так - на клиенте положил в SQLite, добавил данными с сервера, и построил запрос с выборкой нужных данных.

(66) зачем этот геморой, когда база 1с хранится и обрабатываются скл сервером?

(67) Специально для тебя повторюсь:
"Например, получив _тут добавлю, на клиенте_ обширные данные в ТЗ (в частности, как указал ТС, из внешних dbf-ок), нафига их передавать на сервер?"

(66) а зачем данные вообще получать с сервера во внешние дбф???

перейти на 8ку уже советовали ?

(70) восьмерка разжижает мозг©

(68) данные из скл загоняем в дбф, а потом обратно в скл? температура с утра нормальная была?

(70) сразу на оракл, зачем прокладки?

(73) может они с крылашками?

(74) если прокладки с крылышками - думаешь, отчеты летать будут?

(69), (72) Где это я такое писал?

(76) а "обширные данные в ТЗ" пользователь руками набивает?

(75) я не знаю но сиквел лайт, судя по всему легкий и наверное летает?

(77) см., например, (60)

(78) а вообще не понятно нахрена умея одну субд огород городить? Я думаю средства тог же ms sql позволяют работать с dbf

я думаю просто Salimbek наточил руки на SQLLite и ему так проще и быстрее для него, но сомнительно что так наиболее оптимально

(0) >> около 0,8кк документов

Это как? 0,8к = 800 документов
или 0,8 кило-кил, т.е. 800 000 документов?

(79) "внешние дбф" там именно потому, что не хватало памяти для обработки таблиц в памяти.

(0) Это рассчет РПНУ?

(0) аналогичная база на основе Континента, размер 25 гб. Выборки и поиски переписал на прямые запросы. Траблы с подобными отчетами решал разбивая их по видам страхования

(80) Для использования dbf через SQL сервер должен получить доступ к файлу. Уверен что политика безопасности это позволяет?
(83) Если так, то действительно удобнее все в MSSQL делать.
З.Ы. А ведь еще kms интересовался возможностями SQLite: http://www.1cpp.ru/forum/YaBB.pl?num=1187844655

(0) Эххх автор как я тя понимаю, только у мну 8-ка и вся аналитика построена на РБ мать их так ! И ничего другого на ум не приходит как добавлять нормальные РН с нужными разрезами !

(87) гон, в 8-ке куча РН, только разрезы наркоманские...

(88) речь не о типовых, а о той конфе которая мне туты досталась ! 4 субконто + 100500 субсчетов. Это полный алес !

(89) тогда ок...

(25) Как показывает опыт, прямыми руками переписанный алгоритм с использованием стандартных средств 1С в большинстве случаев дает прирост производительности не меньший, чем использование прямых запросов ;-)

(2) Например, получать данные по всем докам одним запросом, для начала.

(68) База - чистый SQL. А для формирования огромных отчетов используются dbf, создающиеся в процессе работы 1с. вот такая хрень мне досталась.
наиболее критичное перепишу под 1с++.

и буду перетаскивать фирму на 8ку.

(84) форма 6 5 11

(92) попробую, только как с памятью? запрос сразу ко всему не съест всю память?

(82) более 800 000 документов. к концу года будет 1 млн... и если ничего не делать, полный капут.

(94) это же мало

для скуля - так вообще смешно

(95) Если на каждый документ в цикле бухзапрос хреначить, то очень много.
Если умеючи, то затоптать можно все.

(87) страхование -континент? на РБ? ой... но выбора нет - до меня купили...
(95) а для имеющихся ;%?%?*:*( обработок - нет. у меня тоже когнитивный диссонанс...

(97) ну, с дуру можно и х.. сломать
:)

А так да, бух запрос в цикле как то не очень

(93) Не съест.

(94) 200 тыс документов за 7 месяцев?  так это немного...

(101) не для этой базы... если повезет, то 1 сентября она останется только в архивах...

(102) У меня тот же "Континент", только перелатанный вдоль и поперек. Некоторые базы даже больше 20-и гигов. Ничего, работаем. Узости на прямых4 запросах переписываем.