Доброго времени суток, дорогие друзья,
Очень прошу уважаемые не посылать гуглить и сёрфить волшебный форум, т.к. это было проделано...
Дано: есть самописная база v7, делается приход позже расхода, такой вот учет... База за 4 года, в день ~600 реализаций, ~30 приходов, делается свертка за день по реализациям, расчет по документам делается через бухгалтерские итоги, ДБФная (на скуле немного дольше происходит проведение, не устроило), пересчет итогов 1 раз в месяц вместе с реиндексом, полный ТиС раз в пол года.
Проблема:  Последнее время пересчет итогов с проведением нужно делать раз или два раза в 10 дней, так как берутся неверные остатки, пишется неверные проводки, миллиарды в суммах, по остаткам на день одно число, за период, если смотреть этот день, другое... Решается только Пересчетом.
Суть вопроса: как можно увеличить срок работы без сбоев?
Курил в сторону: расшифровки файлов RA* RG*, говорят как то можно найти причину сбоев именно в них, так как порой даже после пересчета, в файлах могут быть неверные строки, как это найти и исправить?
есть обработки пересчета регистров, я так понимаю мне они не помогут так как я их не использую? а юзаю бух итоги
последний вариант скуль... говорят на нем можно исбежать такого, но при тестовом переходе  у меня получается на скуле 2005 в 2-3 раза проведение медленней дбф..
В итоге, кто более опытный и как выходил из данного положения, интересуют конкретные решения, без флуда, реальная помощь в поиске проблемы, опуская вопрос с местом роста рук ;)

(0) попробуй с ReconnectNative() если не ошибаюсь на 1С++. Тут ДмитрО как раз тусит - отЭц этого метода

(0)
>>> делается через бухгалтерские итоги
>>>Курил в сторону: расшифровки файлов RA* RG*,
>>>опуская вопрос с местом роста рук

они то как раз и уместны здесь

(0) Место роста рук опустить никак не возможно ))).

По теме.
1. Где все-таки хранятся итоги? В регистрах их бух итогах?
2. Размер самого большого файлика базы - в студию. И имя.

топ 10 дбф по размеру с указанием этого размера

(1) Извините, нашел описание ( специальный метод для решения проблемы с MSSQL 2000 (Bug #: 472280) Выполняет отключение и подключение родного соединения программы с сервером.)
Но причем тут это? у меня даже скуля то нет, написал же, что дбф
(2) не спорю, но не указывать на не правильное :)
(3)(4) 1 - бух итогах
2-
1 533 216 918 ibidata.dat
1 075 281 495 1SENTRY.DBF
695 841 792 1SACCSEL.CDX
579 350 720 1SACCSEL.DBF
412 720 441 DT6085.DBF
259 671 552 1SENTRY.CDX
206 445 266 DT1102.DBF
199 415 458 DT3655.DBF
92 914 918 1SBKTTL.DBF
40 337 610 DT1587.DBF

ibidata.dat - это хрень какая-то от выгрузки / загрузки
если сейчас нет обменов и выгрузок / загрузок - то можешь перетащить куда-нить и потом удалить
все данные в проводках

(5) ну собственно, ты на грани - у тебя файло проводок >1 гига, отсюда неверные числа в отчетиках могут быть
Ну и, от таблички 1SACCSEL можно безболезненно избавиться - убрав отборы по счетам (которыми, стопудово никто не пользуется)

(6) понял, но решение вопроса то не в этом, верно?

(8) решение одно - перейти на SQL

(9) зачем ?

(8) Решение вопроса в скуле с прямыми запросами. Будет одновременно и без сбоев и в 40 раз быстрее...

(11) будет без сбоев и медленнее.
А переписывать запросы под бух итоги - сомнительное удовольствие, даже с классом аккаундрекорсет от И.Берездецкого

(10) а разве можно комфортно работать на DBF с огромными файлами?

(12) С toysql не хужее восьмерки.

Эта база в принципе не для дбф. Они ж каждый день с переиндексации начинают поди. Регулярный полный пересчет итогов это ненормально, хоть раз в пять дней, хоть раз в месяц. Делают-то когда количество глюков уже зашкаливает, а копятся они постепенно. Т.е. в каком-то количестве присутствуют всегда.

(13) нужно

(7) на грани обязательного перехода на скуль?
Отбор уберу - сильно поможет?
(11) спасибо, не подскажете где можно подробнее и с примерами курнуть про работу с запросами в v7?
(12) т.е. я опять в ступоре :)
(14) и как готовить это блюдо?
(15) С переиндексации не начинаем, то что ненормально с пересчетом, и так понятно, за этим и обратился сюда, на счет в каком то количестве они присутствуют всегда, не совсем понятно, каким образом это поможет моей проблеме?

(17)
1.
нет
поможет

(18) честно говоря, такой метод слышу впервые, но проверю, спасибо!

смысел "Курить RA* RG*", если база на бухии?

(17) я эту юзал: http://www.1csql.ru/index.html
автор сюда захаживает. Суть разработки именно реализация функций расчета итогов чтобы ручками не пришлось к итогам на начало месяца движения плюсовать. Медленнее не будет, поверь. Например достаточно сложный отчет ускорял с шести часов до минуты-другой.

Кстати, не совсем понятно как удалось добиться проведения в 2-3 раза медленнее чем на дбф. Для начала во-первых заюзай не 2005, а 2000. Это последний поддерживаемый штатно. Некоторые штатные функции при определенном наборе параметров на 2005 или 2008 могут работать в разы медленнее. Если не ошибаюсь на работе с периодикой натыкался. Сам sql на отдельный сервак ставь, можно виртуальный. С терминалом на одной машине они не очень дружат.

(22) Спасибо, попробую на 2000, но на другой серв перенести к сожалению нет возможности из-за отсутствия оного
(20) ну вроде как там итоги лежат все... хотя возможно я ошибаюсь и там только регистры?

(23).2 только регистры

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

(24) тогда не ясно, как искать проблему с бух итогами :(

(25) Эта дополнительная библиотека позволяет писать прямые запросы, используя имена как в конфигураторе, и некоторые дополнительные функции которых нет в самом sql :) Альтернатива ей 1с++, и вроде как там тоже методы для удобного получения итогов написали, но в свое время ничего внятного не нашел, рекомендовать не могу. В 1с++ приходилось делать это "руками".

(27) подсистема прямых запросов 1с++ сделана именно Павлом.  И для регистров.
А бухподсистему он делал уже в виде коммерческой разработки...

(27) Наверное это как раз то что мне нужно! Спасибо буду пробовать

(29) пока ты будешь "пробовать", тебя уволят к едрени фени.

(30) Что, согласись, было бы логично..

(29) забудь сейчас про прямые запросы. Тебе срочно нужно выбрать один из трех пунктов:
1. переход на скуль
2. переход на альтернативные решения для ДБФ, позволяющие использовать дбф-ки более 1Гб
3. обрезка базы

(32) ключевое слово "срочно"

(27) чтож вы не сказали что это платное удовольствие :)
(32) за советом я и пришел сюда, мне нужно выбрать 1 верный путь,
3- сразу отбрасываем, пока бухия не разрешает
2- какие например?
1- говорят придется базу переписать под прямые запросы? разве быстрый вариант?

(30) ну я вот убрал отбор по счетам, более быстрого метода пока не дали, поможет?

(34) 1. Можно переписать для ускорения, но не обязательно.
2. Спрашивай у Ёпрст4 - он в этом дока. + инфостарте лежат вроде бы.
(35) нет

(34) 1.Вариант небыстрый. но чуть не единственно возможный...
2. SQLite1c, вариант Hogik'а...

Ёпрст4 - кроме SQLite1c еще варианты для использования ДБФного формата более 1 гб?

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

(39) Основные фичи компоненты:

   *


     SQLite версии 3.6.11
   * Движок SQLite доработан в плане регистронезависимости русских символов, нормально работают lower, upper, like, названия таблиц, полей.
   * Добавлено collate _1С - сравнение строк без учета регистра и завершающих пробелов.
   * Отображение ДБФ-таблиц 1С в базу данных SQLite и возможность использовать их в запросах.
   * Работа с ДБФ-таблицами 1С в монопольном режиме.
   * Получение в прямых запросах "длинных" строк 1С-ДБФ.
   * Типизация результатов запроса типами данных 1С.
   * Работа с текстовыми и sql-параметрами в запросах.
   * Укладка в базу данных SQLite ТаблицЗначений.
   * Укладка в базу данных SQLite СписовЗначений с объектами 1С, с возможностью в ДБФ версии разворота групп справочников или счетов по иерархии.
   * Поставщик данных табличного поля 1С++
©Орефков

+(40) Хотя я - не пользуюсь.

(28) sqlite вообще тут никоим боком.
Тебе нужно
1. избавиться от таблички отбор по счетам, убрав отбор с них
2. поставить заплатку от hogik для файлов >1 Гиг.
3. посмотреть "лшнюю" аналитику в проводках по субконто.

База чисто бухня ?
Или комплексная/пуб ?
токма бухитоги у тебя ?

вот еще кое что на эту тематику http://infostart.ru/public/15211/

ну и .. проверить таблички на ошибки:
1.пустые даты в операциях/документах
2.документы с временем 23:59:59 - у них, как правило, время операции не совпадает с временем дока.
3.задвоение, мусор в  iddoc у документов, дублирование id у справочников

(42) чисто бух,  не, только бух тоги
(44) эти три пункта полный ТиС  разве не делает?
(43) это совместимо с заплаткой от hogik'a?

(45)
2.нет
3.это другое решение

(46) Расскажите пожалуйста, как это сделать, корректно, ручками?

что именно ?

(45) вот жиж запугали-то... Первым делом на скуль, если грамотно поставить в 2-3 раза медленнее точно не будет. Проблемы с индексациями пропадут. Далее качаем качаем халявный вариант тойки и начинаем разбирать. Добившись существенного ускорения на каком-нить доке кажем начальнегу, говорим цену (копеечная для конторы), он оплачивает, и дальше спокойно пилим остальное, начиная с самых тормозных мест и по нисходящей. Не уволят, ножки целовать будут, если разберешься...

(49): но в полтора - точно будет.
наф скуль если (42) п.2 - и вперед?..
(скуль по сравнению с файловой - далеко не копейки,Ю кстати)

(50) Ну сам скуль там судя по всему никто покупать и не планирует, благо работает и так.

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

Для бухии скуль не очень поможет по скорости по крайней мере , даже с прямыми запросами , с индексацией будет полегче и с бэкапом
Запас по размерам файла проводок еще очень приличный , есть куда расти

(38)  Год закончился , 1SENTRY.DBF 1.6 гига , работает нормально под терминалкой , правда пользователей не много 11-12 чел по максимум

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

(52) Для начала только самые узкие места убрать, а дельше дело творческое...
(53) А скуль-то об этом и не знает... Он вообще не очень в курсе что он с бухией-то. Ему таблицы и таблицы...

У ТС имхо несоизмеримо небольшой размер файла 1SBKTTL.DBF меньше 1/10 от 1SENTRY.DBF , обычно 1/4 примерно .
Значить практически не используются отборы по субконто , а это очень прилично ускоряет бух запрос особенно когда субконто несколько тысяч (товарный склад например) , перепроведение можно заметно ускорить , за счет некоторого увеличения времени индексирования

(48)  1.пустые даты в операциях/документах
2.документы с временем 23:59:59 - у них, как правило, время операции не совпадает с временем дока.
3.задвоение, мусор в  iddoc у документов, дублирование id у справочников

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

(58) А в бухии индексы отменили что ли? Это ошибочное мнение, что с бух ничего не выйдет. Просто с ней обычно ничего не делают особо, чтобы не иметь проблем при обновлениях. А вообще-то скуль для того и нужен, чтобы из большой таблицы нужные три позиции быстро извлечь. В семерке штатно для начала просто отбор оптимальный не задашь, всегда кучу лишнего притащишь, плюс потом еще так оптимизирует, шо ой. А прямые в ней как раз даже более эффективны нежели в оперучете.

из всего вышеперечисленного я так и не понял, возник спор между дбф и скулём, в моей ситуации пойдет патч от ножика или дбф серверная/клиентская версия от того же ножика или все де лучше скуль с прямыми запросами?

(59) В смысле ясный пень если сравнивать откуда скуль быстрее данные достанет, из регистра или проводок, то не в пользу проводок будет. Но если сравнить прирост в скорости по бухии и тис, то в бух он будет в разы больше.

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

Ладно , завязываем с оффтопом :)

(62) неплохо было бы по теме :)

(62) нука-нука-нука.... А регистры как у нас хранятся? На начало чего у нас итоги-то там? :)

(63) Ну близко так-то... Просто наговаривают понимаешь, что скуль тебе не столь эффективен, вот если бы регистры... Во-первых все с точностью до наоборот. Во-вторых один черт такие объемы не для дбф. Не, можно конечно продолжать жрать кактус с периодическими свертками, но хорошо никак не будет.

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

А вообще по если по теме , бухия такого объема на DBF рассыпаться еще не должна, запас есть

(0) База за 4 года , свернуть не предлагать ?

(67) не

(66) А что за звери такие "произвольные регистры" которые умеют хранить итоги не на начало месяца? :) Единственная принципиальная разница между проводками и регистрами, что у каждого регистра свои rg/ra, а проводки в кучу свалены. И тут скуль против дбф как раз-таки наиболее эффективен.

(69) это мне напомнило спор никонистов и кэнонистов на фото форуме :)

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

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

(70) Не, ну тут другое немного... Тут спор программиста с руководителем походу. Он знает про прямые больше по результату, сам глубоко не копал. У меня же год сидело от 50 до 100 активных в базе страховой на бухучете и не жужжали, а бланки строгой отчетности вам не хухры-мухры, на типовой ложится независимо от компоненты. Просто секрет знаю нехитрый. Пользователю для проведения нужна таблица в два десятка строк из нескольких мульонов что есть в базе. Типовая эска в дбф возьмет таблицу целиком и будет перелопачивать, притом вернет много лишнего, будешь потом еще сам ненужное отсекать. В скуле ненамного лучше, и понятно что быстрее не будет, если читать _все_ записи. Нормальный же скульный можно написать так, что он вернет именно нужные 20 строк, отобрав их средствами скуля, а ему как-то не столь важно из большой таблицы их выбрать или из кучи маленьких. Вот тогда и получается что док проводится в сто раз быстрее. Никаких чудес...

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

(73) В данном случае справляет проблему сама по себе установка скуля. Про итоги и индексы забудешь. А прямые это уже чтобы по скорости после такого перехода стало не хуже, а намного лучше.

(74) ну дык мне про итоги и нужно забыть :)

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

(72) С программистом :) Именно из за того что в скулевской таблице проводок все в куче эффективность отбора по индексу
снижается , при нормальном прямом регистры все равно быстрее , ну и опятьже если есть возможность нужно работать по итогу .

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

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

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

(76) так то оно так, но эти несколько доков нужно сразу поправить, а я не имею опыту построения запросов в v7 только на v8
(77)    Ит = СоздатьОбъект("БухгалтерскиеИтоги");
   Ит.ИспользоватьРазделительУчета(Фирма);
   Ит.Рассчитать(,ТекущийДокумент(),"281",,,Фирма);
далее берем СКД по сумме и кво
(78) ну контрагенты далеко за 100 а вот номенклатура пипец как далеко за...

кстати на будущее, какой есть бесплатный вариант toysql?

(77) Что такое работать по итогу? Работа всегда идет как итог на начало месяца, плюс движения до нужной точки. В toysql для этого есть функции аналогичные одинэсовским, но были ж еще и филиалы где реализовывал своими силами на 1с++. Писать долго, но работает все равно в разы быстрее типовых. Всего лишь только потому что штатно в 1с можно отбирать только на вхождение в список, или поиск конкретной записи. Когда сразу несколько списков юзаешь, получаешь намного больше данных чем нужно, что занимает время, потом из них выбираешь необходимые в циклах, что еще больше его занимает. По сравнению с этим выбор наиболее эффективного индекса в скульном уже не столь критичен.

(81) На сайте поройся, у него демка есть. Размером базы кажись ограничена и количеством пользователей. Понять что за штукенция хватит.

(80) Ууууу , медленно будет , через временные итоги , особенно на дату документа .
Тут только через бухзапрос , тем более если ты используешь фильтр по счетам , должен быть разрешен отбор по счетам

(80) Править штатно будешь. Записывает семерка быстро, так как там ничего избыточного не передается. Только то что нужно.

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

(84) то убрать то поставить, запутался совсем :(
(86) но что? как мне по умному тогда сделать? чтобы работало...

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

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

Если в коде ты увидишь такие штучки как
ВыполнитьЗапрос
ИспользоватьСубконто
ИспользоватьКорСубконто

Причем запрос и выборки относятся скажем к контрагентам , номенклатуре , или субконто счетов реализации
Отбор по данным субконто - включать однозначно

(89) да в том то и дело что у меня весь расчет построен на методе расчитать у всех доков, нет никаких запросов

Если в коде интенсивно используются конструкции ипа ВыбратьСчета или как у тебя Рассчитать с фильтром по счету должен быть разрешен отбор по счетам

(91) Фантастика , как она еще работает то ?

(91) ---> (90)

понял, ага кажись нашел есть в инвентаризации что то типа такого

   Ит = СоздатьОбъект("БухгалтерскиеИтоги");
   Ит.ИспользоватьСубконто("МестаХранения","");
   Ит.ИспользоватьСубконто("ТМЦ",ВыбТовар);
   //Если ПустоеЗначение(ВыбФирма) = 0 Тогда
   //    Ит.ИспользоватьРазделительУчета(ВыбФирма);
   //КонецЕсли;
   Ит.ВыполнитьЗапрос(ДатаДок,ДатаДок,"281",,,,,"СК");
   Ит.ВыбратьСубконто(2);
   Пока Ит.ПолучитьСубконто(2)=1 Цикл
           //бла бла
   КонецЦикла;
оно?

(90) Если включить отбор "ТМЦ" ну и до кучи "МестаХранения" , скорость выполнения конструкции возрастет в несколько раз минимум

База у тебя относительно не большая , если у тебя такой объем наработался за 4 года , два года она как минимум еще протянет , не парься с прямыми запросами и скулем , перепиши на нормальные бухзапросы .
А через пару лет глядишь и на снеговика передут :)

(96) сенкс, wtf снеговик?

По возможности все конструкции типа Ит.Рассчитать , заменить на запрос .
Исключения кончно есть когда имеет смысл временный расчет применять но их не много

Восьмерка :) V8 однака

(99) стесняюсь спросить почему именно "снеговик"?

потому что 8-похожа на 2 комка? :)

8 ничего не напоминает ?
Ну вообще то снеговик из трех снежных шаров делают , но тут на форуме считают что типа у 1С-ников все равно головы нет , так что и двух шаров хватит :)

ну я так и подумал :))))) гггг весело однако

еще и голосовалку прикрутил...

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

в качестве статистики: использую комплексную, в которой табличка 1SENTRY в виде дбф занимала бы около 5-6Гб. Прямые запросы в отношении бухкомпоненты не используются, "сервак" - просто мощная тачка.

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

(104) на счет "ножика" кто-то на форуме писал что атк читается, ходжик и ежик вроде как-то не то :)

(105)
>>табличка 1SENTRY в виде дбф занимала бы около 5-6Гб

вот только не надо привирать то.
Больше 2 Гигов она не может быть физически.

+108 в лучшем случае, в advantage database server можно поиметь файло в dbf в 4 гига (и то, там свой "dbf" формат)

(109) в 105 написано "занимала бы"

Ёпрст4 у меня скуль.Я просто привел пример размера таблички в БД.
Кстати я приврал - 3,7Гб

(111) интересно, как ты это посчитал...

(112) Анализ таблиц базы данных SQL(1cpp).ert

(113)+ автор обработки pvase

ТС на данных объемах базы ИМХО еще о скуле и прямых запросах думать , достаточно переписать все на нормальные бухзапросы и включить отбор по тяжелым субконто

(111) п..ц
Какое отношение размер таблички в скуле имеет к dbf ?

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

Только вот к дбф это не имеет никакого отношения.

(117)Ув. Ёпрст4, как по вашему мнению, если как мне писали, недавно, все таки включить отборы по счетам и субконто в особенности товары, потом сделать в обработке проведения запросом по бух итогам получение кво и суммы, это решит проблему???
Вы писали наоборот отключить отборы по счетам, а далее написали, их нужно обязательно включить и писать запрос, а не временный расчет, как у меня, как лучше и правильней?

(118) у тебя и так включен отбор по счетам - вон как табличка распухла.

+119 при отключенном отборе, таблички 1SACCSEL не было бы вообще.

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

Имхо, не нужен.
Выключи на тестовой конфе да проверь замером производительности - она не упадёт ни разу.

(122) если я вас правильно понял мне нужно всего лишь отрубить отбор по счетам, оставить расчеты по проводкам как есть и пусть живет кернел37 от ножика, это решение?

Не ножик а hogik

(124)sorry, а если так взглянуть "Hogik"?
и к сожалению ответа я так и не получил

а так, можно еще ускорить твою бухию, например, выкинуть аналитику на 41 счете.
твоя табличка проводок похудела бы раз в 10

ага неплохо было бы, только бухия укр а рус :)

(123) Отбор по счетам можно отрубить , если не используешь фильтры по счетам . Если у тебя все через Рассчитать то фильтры по счетам по любому используются .
Вот наверное самописчик делал все через рассчитать и включал отборы по счетам , а бухзапросом почти не пользовался и отключил отборы по субконто

(128) спс