Sapforum.Biz

Если в не ту тему просьба перенести (может это будет продолжение темы "Оптимизация АБАП").....

В общем ситуация такая, есть отчет "Список счетов-фактур", в нем выводится кроме всего прочего №НН (налоговой), который берется с bkpf (если не ошибаюсь), стоит задача вытягивать еще и сумму/налог с налоговой.

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

По реализации - буду на работе напишу точнее .....

Ребята (девочки  :)) с FI посоветовали брать данные с bset, он поменше (у нас на каждую НН 2 запси). Быстренько переделал .... таже ф-ня, правда валится не так часто.

Теперь по реалиазции: в обоих случаях выбирал сначала во внутреннюю табличку, и лупом подсчитывал сумму, так как табличка то кластерная, и просто SELECT SUM(XXX) не канает.....
  SELECT *
      INTO CORRESPONDING FIELDS OF TABLE zbset
      FROM bset
        FOR ALL ENTRIES IN gt_nn
      WHERE bukrs = bukrs        AND
            belnr = gt_nn-belnr  AND
            gjahr = gjahr        AND
            shkzg = 'S'          AND  " дебет
            hkont like '0064%'.

  DESCRIBE TABLE zbset  LINES cnt.

  LOOP AT zbset .
     wrbtr = wrbtr + zbset-HWSTE.
  ENDLOOP.

может есть у уважаемого ALL, хоть какието идеии ? Вьюху сдалать не получилось - по причине тогоже ...


Та что надо знать АБАП, ой надо .....  :)

Переехало в SE38, так как все таки тема абаперская...

---

А по теме:

FOR ALL ENTRIES IN gt_nn <- Тут у нас что, сколько записей и вообще может иногда этих записей там нет?

Цитата: Паганель від Листопад 11, 2008, 08:19:52 ПП
может есть у уважаемого ALL, хоть какието идеии ?

А select * обязательно? Длина записи под 300 байт всё-таки...

В gt_nn - выбраные налоговые ....

По поводу

ЦитатаА select * обязательно?

, так вроде бы  INTO CORRESPONDING FIELDS OF TABLE zbset
работает быстрее.

Вообщем буду смотреть на индексы ......

Цитата: Паганель від Листопад 12, 2008, 09:32:25 ДП
Вообщем буду смотреть на индексы ......

Там индекс только один и других быть не может ;)

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

Присоединяясь к вышесказанному: лучше не полениться и перечислить нужные поля и сделать SELECT [ПЕРЕЧЕНЬ ПОЛЕЙ ТАБЛИЦЫ ITAB] INTO TABLE ITAB - самая быстрая конструкция. Ну а про FOR ALL ENTRIES № 1 в теме про оптимизацию уже писал: если вн. таб. пустая - лопатится вся BSET... А для подсчета суммы и налога никак не выкрутиться используя BSID/BSAD?  

Цитата: Паганель від Листопад 12, 2008, 09:32:25 ДП
В gt_nn - выбраные налоговые ....

По поводу, так вроде бы  INTO CORRESPONDING FIELDS OF TABLE zbset
работает быстрее.

Вообщем буду смотреть на индексы ......

Не быстрее будет INTO TABLE а не CORRESPONDING FIELDS OF TABLE...  причем значительно быстрее будет...

Индексы смотреть конечно можно, но налоговых там дофига у тебя выбирается, так что врядли ускорить что получится. А пробовал сделать без FOR ALL ENTRIES? А типа точечными запросами по каждой налоговой выборку делать?

Кстати а какое время работы диалогового процесса у тебя выставлено?

по поводу CORRESPONDING FIELDS OF TABLE - сейчас перечитываю твой труд по оптимизации (это кстати почти сразу описано)

ЦитатаА типа точечными запросами по каждой налоговой выборку делать? 

так там и есть по одной СФ все налоговые (их обычно 1, может две).

ЦитатаКстати а какое время работы диалогового процесса у тебя выставлено? ......

диалоговый процесы тут не причем, валится не по таймауту, а в дамп дохрена памяти жрет.

Тут ошибка даже не в програме, а в ДНК  ;)

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

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

память превышает 2-3 гига, пользователи и админы бузумно рады, дампам и т.д.  :)

Цитата: Dmitriy від Листопад 12, 2008, 11:32:50 ДП
Присоединяясь к вышесказанному: лучше не полениться и перечислить нужные поля и сделать SELECT [ПЕРЕЧЕНЬ ПОЛЕЙ ТАБЛИЦЫ ITAB] INTO TABLE ITAB - самая быстрая конструкция. Ну а про FOR ALL ENTRIES Uukrul в теме про оптимизацию уже писал: если вн. таб. пустая - лопатится вся BSET... А для подсчета суммы и налога никак не выкрутиться используя BSID/BSAD?  

вот сел писать

Цитатаgt_nn - не пустая, все класно

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

ЦитатаBSID/BSAD?

Пока как бы не нашел тех данных что мне нужны в этих табличках, завтра поспрашаю у наших FI-щиков, если сам не разберусь  :)

Конечно, оптимизировать буду, сейчасвот почитаю труд господина Уукрула по оптимизации, подумаю .....

Всем спасибо, получется отпишусь в чем были траблы, но прием советов не прекращаю  :)

Цитата: Паганель від Листопад 12, 2008, 09:34:22 ПП
вот сел писать  сижу и думаю, это у меня в теста не пустая, а в пользователей,

В общем смотри что будет лучше сделать с gt_nn... если там записей всего-то 1-10 тогда может данные объявить как RANGES и туда их затолкать, тогда условие WHERE будет типа через OR этих там 1-10 условий подставятся там в запрос... ну или пере вызовом селекта проверять на содержимое gt_nn, если ничего нет тогда запрос не делать, чтобы небыло фулскана таблицы.

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

Цитата: Dmitriy від Листопад 12, 2008, 11:32:50 ДП
Присоединяясь к вышесказанному: лучше не полениться и перечислить нужные поля и сделать SELECT [ПЕРЕЧЕНЬ ПОЛЕЙ ТАБЛИЦЫ ITAB] INTO TABLE ITAB - самая быстрая конструкция. Ну а про FOR ALL ENTRIES Uukrul в теме про оптимизацию уже писал: если вн. таб. пустая - лопатится вся BSET... А для подсчета суммы и налога никак не выкрутиться используя BSID/BSAD?  

извините, а что это влечеть - время выборки или рост используемой памяти ?

Цитата: Паганель від Листопад 13, 2008, 02:02:14 ПП
извините, а что это влечеть - время выборки или рост используемой памяти ?

При перечеслении по порядку только нужных полей в определении вн. таблицы и непосредственно в синтаксисе запроса для выборки в нее с использ. конструкции INTO TABLE сокращается и то и другое. Дебиторка лежит в BSID(отк.поз.) и в BSAD(закр.), соответственно кредиторка в BSIK/BSAK. Налог можно подсчитать вытягивая процентную ставку (не обращайть внимание на SELECT...ENDSELECT, код древнее поповской собаки, оптимизируете, если что):
Поскольку данные приходиться добивать точечными запросами для получения налоговых показателей (каких, кстати, помимо указ-го в 1-м посте?), а прога валиться в дамп по нехватке памяти, то нужно вычислить момент, когда это происходит, и если это основная выборка с-фактур, то тогда несколько вариантов:
1) увеличение памяти (базис не в восторге будет)
2) SELECT...ENDSELECT с обработкой и сливом внутри него уже подготовленных данных в итоговую вн. таблицу
3) если и п.2 не поможет, то настаивать на п.1 или менять подход к решению задачи вплоть до постановки
Если дампит в процессе обработки выбранных с-ф., то можно:
1) дополнить вн. таблицу с-ф., получ. при первой выборке, полями так, чтобы ее можно было выводить как итоговую, т.е. работать только с ней используя LOOP AT itab_sf ASSIGNING <fs_itab>...ENDLOOP, где <fs_itab> LIKE LINE OF itab_sf.
2) после выборки с FOR ALL ENTRES очистить вспомогательную вн. табл.: FREE gt_nn
Больше пока ничего на ум нейдет, т.к. не знаю конкретной задачи   

Цитата: Паганель від Листопад 13, 2008, 02:02:14 ПП
извините, а что это влечеть - время выборки или рост используемой памяти ?

У меня подозрение, что при пустой таблице gt_nn у тебя вся BSET-а втягивается, так что или проверяй перед вызовом запроса gt_nn на заполнимость илиз попробуй механизм предложенный Dmitriy-eм.

Цитата: Uukrul від Листопад 13, 2008, 03:16:30 ПП
У меня подозрение, что при пустой таблице gt_nn у тебя вся BSET-а втягивается, так что или проверяй перед вызовом запроса gt_nn на заполнимость илиз попробуй механизм предложенный Dmitriy-eм.

Я чего-то думал что в данном случае не выбирается ничего (сумма пустая), и естественно память не растет

Т.е. получается, что ларчик-то просто открывался? :)

Цитата: Dmitriy від Листопад 13, 2008, 04:13:16 ПП
Т.е. получается, что ларчик-то просто открывался? :)

Ну щаз автор пошаманит и скажет наверное чего  ::)

Немного подправлю (редактирование недоступно):
Конечно же FREE gt_nn[]. Рекомендую очищать занимаемую память от данных, которые в процессе дальнейшей обработки не нужны, причем не только в данном, конкретном случае, а почти всегда, т.к. может быть открыто несколько сессий, а память, выделямая на одного юзера не зависит от их кол-ва и есть CONST.

2 Администрация: предлагаю создать отдельную тему типа "Технология написания программ на ABAP" или "Особенности ....." или просто "Полезные фишки" и т.д., как и для оптимизации, ориентированну на уже достаточно продвинутых SAPеров. Есть много моментов, знание которых очень помогает в том или ином случае.

2 Паганель: надеюсь, вопрос "Знать или не знать ABAP" уже отпал сам собой? :)

Цитата: Dmitriy від Листопад 13, 2008, 05:25:58 ПП
Немного подправлю (редактирование недоступно):

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

Цитата: Dmitriy від Листопад 13, 2008, 05:25:58 ПП
2 Администрация: предлагаю создать отдельную тему типа "Технология написания программ на ABAP" или "Особенности ....." или просто "Полезные фишки" и т.д., как и для оптимизации, ориентированну на уже достаточно продвинутых SAPеров. Есть много моментов, знание которых очень помогает в том или ином случае.

Не вопрос, готово: http://sapforum.biz/index.php/board,29.0.html будешь там главным  ;)

Цитата: Dmitriy від Листопад 13, 2008, 05:25:58 ПП
Немного подправлю (редактирование недоступно):
Конечно же FREE gt_nn[]. Рекомендую очищать занимаемую память от данных, которые в процессе дальнейшей обработки не нужны, причем не только в данном, конкретном случае, а почти всегда, т.к. может быть открыто несколько сессий, а память, выделямая на одного юзера не зависит от их кол-ва и есть CONST.

2 Администрация: предлагаю создать отдельную тему типа "Технология написания программ на ABAP" или "Особенности ....." или просто "Полезные фишки" и т.д., как и для оптимизации, ориентированну на уже достаточно продвинутых SAPеров. Есть много моментов, знание которых очень помогает в том или ином случае.

2 Паганель: надеюсь, вопрос "Знать или не знать ABAP" уже отпал сам собой? :)

так он вообще-то отпал уже давно   :)  (см. пост в соответствующей ветке )

А по теме данного поста: у меня данная табличка обьявлена как локальная (в теле подпограмы) и я думал что память очищается сама собой (наверное сыграла привичка с Делфей)  :)

Как я понимаю, абап ближе к Яве, и тут присутствует какой-то сборщик мусора?