Возникает следующая ситуация:
При добавлении в таблицу очередной записи система вылетает с ошибкой:


The current program had to be terminated because of an
error when installing the R/3 System.
The program had already requested 1142179120 bytes from the operating
system with 'malloc' when the operating system reported after a
further memory request that there was no more memory space
available.

к тому моменту в таблице уже Table[1005264x821]. Какие действия можно предпринять, чтобы не возникала следующая ошибка. И как кроме ограничений по выбору, эту ситуацию избежать.

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

ого ... этож гиг почти!!!

Ну вообще-то ничего удивительного - буквально берете данные по развесистому контроллингу за финансовый год (и даже не за целый) во внутр табличку - и вы победитель

примерно да, только, это видимо ответ на вопрос откуда столько, а не на "что делать"

Ответ на вопрос был дан во втором посте.

З.Ы.: Есть еще аппаратный способ решения проблемы. Называеется вбухивание денег в железо из-за нежелания что-то оптимизировать

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

Главное, скока средствов освоить мона...

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

Если SELECT ваш собственный, то обратите внимание на оператор OPEN CURSOR.

А что, пользователям нужны прямо все эти 1005264 записей? Не поверю. Человек столько не в состоянии анализировать.
Может какую-то выжимку надо? Стоит уточнить у пользователей что они конкретно хотят в итоге получить.

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

Возможно, агрегатные функции в select'е помогут. SUM вместе с GROUP BY, например.

Если Open SQL слабоват, то можно, по желанию, Native SQL попробовать.

Да скорее все так и есть, юзер хочет все и по всему - SELECT * FROM *
Они потом готовы все это распечатать и на коленках по распечатке ползать, выискивая "цифирь". Видел таких и неоднократно. Попытку посоветовать более эффективный способ работы обычно воспринимают как оскорбление.

А можно код в студию?



Может стоит также обратить внимание на число 821? Вам действительно все это нужно? Вроде бы "ширина" тоже на объем памяти влияет (или я что-то путаю?).

У меня один раз была проблема - приходилось считывать 1 млн.+ записей из базы в internal table, потом их преобразовывать и создавать практически вторую такую же, только с измененными данными. Программа считывание прошла нормально, но вот на втором миллионе споткнулась. Вылечили тем, что стали стирать первую таблицу сразу же в цикле, при создании второй. Правда там было не 821, а максимум 200...