Есть запрос, который выбирает срез всех остатков по регистру бухгалтерии. Затем этот срез выгружается в набор записей.
Проблема в том, что если результат запроса ну очень большой, то при работе запроса вылетает сообщение "Недостаточно памяти" и работа программы прекращается. Как это забороть? Можно как то запросом выбирать данные кусками? Проблема в том, что на уровне разработки заранее состав измерений регистра неизвестен. Ключевое слово запроса "ПЕРВЫЕ", позволяет выбрать лишь первые N записей, а вот как выбрать последующие?

Даже сразу и не придумать.

Для РегистраНакоплений то все понятно, как "кусок пирога", а для РБ проблема в том, что условие на Счет и на Субконто в параметрах ВТ - в разных разделах!

А учитывать их нужно в связке.

А отбирать только по Счетам - не факт, какой-нибудь 10 или 41-ый даст прикурить нехило.

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

(4)10 и 41 по складам можно разбить

Ведь явно или номенклатура или контаргенты/договоры так сильно нагружают.. Ну может ОС ещё..  
А если эти справочники кодом ограничить? Типа Субконто1.Код <=1000000 И Субконто1.Код>1000000

(7) Хосподя...

(6) Можно. Но автору нужен универсальный механизм.

ГДЕ
   ВЫБОР
           КОГДА ХозрасчетныйОстатки.СуммаОстаток - (ВЫРАЗИТЬ(ХозрасчетныйОстатки.СуммаОстаток КАК ЧИСЛО(15, 1))) > 0
               ТОГДА (ХозрасчетныйОстатки.СуммаОстаток - (ВЫРАЗИТЬ(ХозрасчетныйОстатки.СуммаОстаток КАК ЧИСЛО(15, 1)))) * 100
           ИНАЧЕ -(ХозрасчетныйОстатки.СуммаОстаток - (ВЫРАЗИТЬ(ХозрасчетныйОстатки.СуммаОстаток КАК ЧИСЛО(15, 1)))) * 100
       КОНЕЦ = &НомерИтерации

Вот алгоритм неравномерного деления данных об остатках на 10 итераций

(10) ну вот это интересно. Интересно насколько это затормозит запрос. Т.е. насколько эти 10 будут медленнее выполняться, чем тот один. И ещё, если условие расположить в секции ГДЕ разве всё-равно не будет строиться исходный запрос по виртуальной таблице, а затем из него данные уже отбираться. Т.е. таким образом сможем мы решить проблему нехватки памяти?

Сервер 1с 64х уже предлагали купить?

(0)На каком количестве записей затыкается?

(11) Я думаю, что не сильно ошибусь, если скажу что 10 таких запросов будут работать в 10 раз медленнее одного запроса. Что касается памяти, не думаю, что нехватка возникает именно в момент выполнения запроса. Думаю, что нехватка возникает позже, в момент получения результата или выборки.
Что касается того, где использовать условие, если есть возможность использовать его в параметрах виртуальных таблиц - делай так. Насколько я знаю, в виртуальной таблице Остатки регистра бухгалтерии такой возможности нет.
Короче, идея ясна, а дальше - твоё творчество. Методика легко трансформируется в любое количество итераций. На неё сверху можно наложить любое ограничение (по счету, по субконто, по измерению-разделителю типа организации и т.п.)

Отпишись о результатах...

(12) На нем родном и затыкается.
(14) Не знаю, может сделаю, как вы указали, но по коду первого субконто. Субконто в параметры виртуальных таблиц можно поставить. Только надо в запросе как-то узнать что оно, это самое первое субконто есть и оно справочник, опять таки код у первого субконто может быть как числовым, так и текстовым, тоже распознать как-то нужно. На языке запросов такие плюшки сложно сделать. Буду думать.
Всем спасибо.

Посмотреть количество, отсортировать, выбрать половну (первые), отсортировать обратно, выбрать вторую половинц

(16) Точно! Давно хочу в запросах такую конструкцию как
"Выбрать Первые 50%"

(15) Наверное, надо не сервере выполнять, а не на клиенте.

(0) если на клиенте отваливается, то использовать Выборку, и записывать порционно в регистр

если на сервере, то поставить 64-разрядный, если не помогло - доставить память, если и это не помогло, то фильтровать в запросе по измерением, если ничего не помогло - то пересмотреть архитектуру структуру хранения данных

дущ, разбей для начала запрос по одному измерению, данных в памяти будет меньше потом результат запроса подроби на n таблиц, и в последующие запросы передавай как параметр, поидеи данные по одному из n измерений должны быть намного меньше, хотя сервер будет выполнять те же действия(да и возможен поиск по неполному индексу index seek where) но на клиента приходить будет меньше...

Хотя задача весьма подозрительная, обычно взять весь оборотку по РБ(организации которая работает 3-4 года) не составляет труда... может надо запрос оптимизировать, ты бы показал его

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

>как отобрать последующие (0)
Извратно Книга знаний: v8: Нумерация строк в запросе

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

+(22) Проще в ТЗ выгрузить

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

(25) Т.е. лучше спрятать проблему за псевдоправдоподобностью? Ещё неизвестно, что хуже.
В общем-то от задачи это зависит. Если это выгрузка данных, то подразумевается некая неизменность данных на каком-то отрезке времени, пока осуществляется выгрузка.

(0) Сколько записей получается? Что потом с ними делается?

IMHO пора пересматривать алгоритмы.

Ну задача проста, данные не изменяются. В момент работы моей обработки база открыта в монопольном режиме. Только не пойму, как это может мне помочь. ВЫБРАТЬ ПЕРВЫЕ 50% к сожалению нет.
Плюс структура регистра заранее неизвестна, запрос конструируется "на лету". Какие там измерения (и есть ли они), сколько по каждому разрезу данных, тоже неизвестно.
(18) так и так на сервере выполняют (физически). Плюс помойму в обычном режиме итак все запросы выполняются на сервере.
(19) выборка очень медленно работает. Запрос должен за ночь, максимум за сутки отрабатывать базу в 40-50 ГБ.
(20) в том и дело, я даже не знаю, будут ли измерения у регистра, соответственно и разбить его не могу.

Ищу конструкцию языка запросов по фильтрации виртуальной таблицы остатков регистра бухгалтерии по первому субконту счета (если есть).по коду этого субконто (если это справочник или ПВХ).по первой букве(если это буква)/цифре (если это цифра)

Что-то вроде этого:

ВЫБОР КОГДА Субконто1 = Неопределено(или NULL, что тут будет если субконто нет) ТОГДА
ИСТИНА
КОГДА ПОДСТРОКА(ТИПЗНАЧЕНИЯ(Субконто1), 1, 5) <> "Справ" ТОГДА
ИСТИНА
КОГДА ПОДСТРОКА(Субконто1.Код, 1, 1) = &ЦифраОт0До9 ТОГДА
ИСТИНА
ИНАЧЕ
ЛОЖЬ
КОНЕЦ

только сдается мне, что ПОДСТРОКА(ТИПЗНАЧЕНИЯ(Субконто1), 1, 5) явно не прокатит, с преобразованием типов в запросах, помойму, беда.

(28) это вообще не нужно. ЕСли субконто нет у счета, данные не попадают. Нукаких ВЫБОРов не нужно.