Посмотрел примеры Native SQL. Там предлогается читать данные либо все сразу, либо по строкам (FETCH). А есть ли возможность чтения пакетами по n-записей? Причем синтаксис должен быть универсальным для нескольких БД (Oracle, DB2), но не Open SQL.

хе хе... еще один
Нету. Пользуйтесь OpenSQL

Я соединяю много таблиц > 25. Open SQL падает. Так что хе-хе не уместно.

Дополнительный вопрос. В Open SQL есть опция WITH HOLD, которая удерживает курсор в открытом состоянии. Как быть с этим в Native SQL, если прочитав ну скажем 100 000 в одном пакете мне надо сохранить их в другой таблице, выполнив COMMIT? Как оставить курсор открытым?

Да уж... Здесь уместно ой-ой-ой.

Прошу прощения, если вы в одном запросе соединяете >25 таблиц, значит что-то не так с постановкой задачи. Скорее всего придется разбивать на несколько запросов.

С постановкой все так. Посмотрите какой SQL генерится BW-запросами. Я пишу инструмент, позволяющий читать данный инфо-куба и такое количество таблиц в join-е - это привычное дело. Тоже сначала стал использовать Open SQL. На кубах с простой структурой он работал, а когда таблиц стало много - стал валиться.

Еще вопрос. Поскольку SQL я генерю, то он у меня получается типа string - то есть динамический. Внимание, вопрос! Как в Native SQL выполнить динамический запрос?

generate subroutine pool поможет.

2 sibrin

...уже

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

Не фиксируйте, пишите пакет в табличку. Потом коммит, а из таблички потом построчно в транзакцию.
Но в любом случае - так работать не совсем здраво. 25 таблиц. BW может. А руками - это по-моему велосипед изобретать.
Проанализаруйте. Может и не нужно все таблицы связывать. Предобработка рулит.

2 Zharik

Данных много и писать все во внутреннюю таблицу с одним commit-ом - нереально, ресурсов не хватит.

Кто сказал что руками? Генерируется запрос кодом, а базируется он матописании BW-шных объектов - там и 40 таблиц может быть соединено.

Так что ваши решения отметаются, как несостоятельные.

Посмотрел в отладчике что делает BW...

- анализ метаописания

- генерация SQL

- проверка возможности исполнения запроса Open SQL (если таблиц < 25), иначе определить тип БД, сгенерировать VIEW в БД с использованием Native SQL (для VIEW генерится уникальное имя), прописать VIEW в системных DD*-таблицах, чтобы ее мог подхватить Open SQL

- в случае с Open SQL открыть WITH HOLD-курсор с генерированным запросом, а в случае с Native SQL открыть Open SQL WITH HOLD-курсор на основе сгенерированной вьюхи

- FETCH-им записи

- для Native-подхода удаляем VIEW из DD*-таблиц и из БД

Вот такой хитрый SAP. Если не найду пути проще придется детально разбираться в фашистком коде и реализовывать также

2 perishkin
А вы не пробовали юзать ФМ чтения инфопровайдера? Чем она не устраивает? Или стоит задача новый BW писать

Задача стоит соединить куб и ODS по некторорым полям и получить данные куба, так что стандартные ФМ не подходят

Если мало памяти - пиши всё в файл на сервере приложений. А потом уже из него читай. Или в 10000 файлов по 1000 строк, чтобы меньше памяти занимать.
Если делаешь что-то слишком нестандартное - готовься к извращенным решениям.

А может проще средствами BW произвести пересечение куба с ODS и полученный объект данных читать ФМ или другим стандартным способом - потом куб поменяют - добавят что нибудь - таблиц станет не 25 а 45 - и что потом ...

2 dump

Средствами BW сделать пересечение куба и ODS? Ну, если подскажите как, попробую... Что касается количества таблиц, то уже
написал на Native SQL чтение произвольного куба, осталось дописать функционал пересечения. Так что потом - суп с котом.