Имеем следующее

Есть собственный экстрактор, который извлекает данные через функциональный модуль. Данные должны извлекаться по-пакетам. Размер пакета попадает (как это везде сделано в стандартных екстракторах) через IMPORT Parameter
I_MAXSIZE TYPE SBIWA_S_INTERFACE-MAXSIZE

Далее примерно следующее

OPEN CURSOR WITH HOLD G_CURSOR FOR
SELECT * FROM (TABLENAME).....

FETCH NEXT CURSOR G_CURSOR
INTO TABLE ITABLE
PACKAGE SIZE I_MAXSIZE.

Всё вроде нормально. В RSA3 работает и извлекает данные по-пакетам. А вот в обычном режиме (через инфо-пакет) не хочет разбивать данные на блоки. Хотя в параметрах инфо-пакета я прописал максимальный размер блoка данных.

Никто не подскажет в чём проблема ?

Всё вроде верно и должно работать, а пробовали НЕ указывать размер пакета (I_MAXSIZE) во вкладке IMPORT.

посмотрите в исходной системе настройки управляющих параметров для переноса.

цитата из хелпа

2. Maximum Size of the Data Package
When you transfer data into BW, the individual data records are sent in packages of variable size. You can use these parameters to control how large a typical data packet like this is.

If no entry was maintained then the data is transferred with a default setting of 10,000 kBytes per data packet. The memory requirement not only depends on the settings of the data package, but also on the size of the transfer structure and the memory requirement of the relevant extractor.

3. Maximum Number of Rows in a Data Package
With large data packages, the memory requirement mainly depends on the number of data recrods that are transferred with this package. Using this parameter you control the maximum number of data records that the data package should contain.

By default a maximum of 100,000 records are transferred per data package.

The maximum main memory requiremen per data package is approximately 2*'Max. Rows'*1000 Byte.

Может это вам подскажет, почему не режется на пакеты так как вам хочется?

И еще. посмотрите внимательно код ФМ RSAX_BIW_GET_DATA_SIMPLE

Сдается мне, что вы делаете fetch в свою таблицу ITABLE а надо в стандартную таблицу возврата E_T_DATA.

Да нет. Я как раз в E_T_DATA всё записываю. Здаётся мне, что тут ручками придётся в какие-то таблицы типа ROOSPRMS ABAP-кодом значения прописывать...

В настоящий момент я "победил" эту хрень очень просто. Прямо в коде функционального модуля прописал в явном виде значение I_MAXSIZE = 50000. Но это не есть хорошо.

Скажи, а откуда такая необходимость - разбивать по блокам, с чем это связано?

[quote="Bkmz]
Скажи, а откуда такая необходимость - разбивать по блокам, с чем это связано?[/quote]

А попробуйте загрузить в ODS пару миллионов записей... Так, если даже пакет удастся перегнать, то ODS будет активироваться хрен-знает сколько...

А попробуйте загрузить в ODS пару миллионов записей... Так, если даже пакет удастся перегнать, то ODS будет активироваться хрен-знает сколько...[/quote]

тогда это не поможет... активация идет всего запроса, а не блока запросов...

хм, мульен по ходу надо бить не размерами пакета а критериями выбора, типа 200 тыс. записей за 2005 год - это один запрос, 300 тыс за другой год и т.д.

Да можно несколько пакетов сделать или динамически RANGE задавать

Тока нежелательно в моём случае. Задачу только что запустили в продуктив, требования меняются. И очень большая вероятность того, что все данные придётся перегружать и не один раз. А тут за день приходит в среднем 50000 - 100000 новых записей. (Это база телефонных переговоров центра обслуживания клиентов, соединенная с CRM). А если еще пара-тройка регионов подключится, так и все 300000 записей за день - вполне реальная цифра. Вот и попробуйте данные за пару месяцев перегрузить.

Вот, кстате, проверим BW "на вшивость".

Кстате, проверял здесь. Длительность загрузки данных в ОДС еще как зависит ит того, пересылаются данные одним пакетом или блоками. Кроме того, где-то находил в САП-овской документации зависимость размера необходимых буферов от размера пакета. Сейчас нет времени искать.

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

Сдается мне что в данном случае ты проверишь не BW на вшивость, а оракл вместе с железом на котором он стоит.
Кстати, прежде чем гнать такие объемы неплохо делать расчет железа для такой задачи на sap'e а то много сюрпризов может вылезти