Меню

Заметки старого АБАПника

|

Производительность на стандартной, сортированной и хешированной внутренних таблицах.

3. Производительность на стандартной, сортированной и хешированной внутренних таблицах.

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

REPORT  ZQK003.
data
  : begin   of gs
  ,   nnn type n length 10
  , end     of gs
  , gt1   like standard table of gs with non-unique key nnn
  , gt2   like sorted   table of gs with unique key nnn
  , gt3   like hashed   table of gs with unique key nnn
  , a     type i, b type i
  , t1 type i, t2 type i, t3 type i
  , count type i
  , goal  like gs-nnn
  .
parameters power type i default 20.

start-of-selection.
  do power times.
    count = 2 ** sy-index.
    refresh gt1.
    do count times.
      gs-nnn = sy-index.
      append gs to gt1.
    enddo.
    gt3 = gt2 = gt1.
    goal = count - 1.

    get run time field a.

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев46

Комментарий от  

Олег Точенюк

  |  31 октября 2014, 00:44

"Оказывается, время поиска в хешированной таблице таки зависит от размера" - Таки не может, хеш-функция, на то и функция что она определяет положение записи, но ваше утверждение звучит так, что в зависимости от значений a, b и c, скорость расчета программой квадратичного уравнения ax^2 + bx + c = 0, таки разная и знаешь если это погонять, то в миллисекундах ты таки тоже получишь разные значения на вызов функции расчета такого уравнения.
 
Реклама, что ли: sapland.ru/books/rekomendatsii-po-optimizatsii-programm-na-yazike-abap.html там есть найденные на просторах SCN принципы организации внутренних таблиц, ну это чтобы не замерять, то что смысла замерять нет.

Комментарий от  

Александр Дублин

  |  31 октября 2014, 12:16

"Оказывается, время поиска в хешированной таблице таки зависит от размера" - Таки не может, хеш-функция, на то и функция что она определяет положение записи, но ваше утверждение звучит так, что в зависимости от значений a, b и c, скорость расчета программой квадратичного уравнения ax^2 + bx + c = 0, таки разная и знаешь если это погонять, то в миллисекундах ты таки тоже получишь разные значения на вызов функции расчета такого уравнения.
 
Реклама, что ли: sapland.ru/books/rekomendatsii-po-optimizatsii-programm-na-yazike-abap.html там есть найденные на просторах SCN принципы организации внутренних таблиц, ну это чтобы не замерять, то что смысла замерять нет.

Со вчерашнего дня за эту книгу можно произвести оплату карточкой прямо на сайте.

Комментарий от  

Денис Озорнов

  |  18 ноября 2014, 09:51

На мой не скромный взгляд: тест по хэшу ни о чем.
1) скорость измерения для хэш-таблы не коррелирует линейно с числом строк в таблице
2) речь идет о микросекундах, т.е. скорее всего это погрешности связанные с накладными расходами на обслуживание работы с таблой собственно, а не на поиск.
3) для чистоты замеров стоит исключить перекладывание найденных данных, использовав вместо INTO конструкцию TRANSPORTING NO FIELDS
4) если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы.
ЗЫ: Непонятно про рекламируемую книгу: зачем она, если есть первоисточники
sap-press.com/abap-performance-tuning_2092

Комментарий от  

Юрий Сычов

  |  18 ноября 2014, 09:58

На мой не скромный взгляд: тест по хэшу ни о чем.
1) скорость измерения для хэш-таблы не коррелирует линейно с числом строк в таблице
2) речь идет о микросекундах, т.е. скорее всего это погрешности связанные с накладными расходами на обслуживание работы с таблой собственно, а не на поиск.
3) для чистоты замеров стоит исключить перекладывание найденных данных, использовав вместо INTO конструкцию TRANSPORTING NO FIELDS
4) если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы.
ЗЫ: Непонятно про рекламируемую книгу: зачем она, если есть первоисточники
sap-press.com/abap-performance-tuning_2092

4) книга на русском. и она дешевле :)

Комментарий от  

Денис Озорнов

  |  18 ноября 2014, 10:05

4) книга на русском. и она дешевле :)

1) очень печально, если программер не может читать на английском хотя бы тех.литературу
2) - папа, зачем ты пьешь водку из горла? Возьми стакан!
   - Сынок, папе не нужны посредники!

Комментарий от  

Юрий Сычов

  |  18 ноября 2014, 11:39

1) очень печально, если программер не может читать на английском хотя бы тех.литературу
2) - папа, зачем ты пьешь водку из горла? Возьми стакан!
   - Сынок, папе не нужны посредники!

печально то, что в СНГ только 2 нормальные книги на русском: Виталия Поцелуева и Олега Точенюка.
 
далеко нам уже до индусов и остальных - те книги пачками выпускают.

Комментарий от  

Денис Озорнов

  |  19 ноября 2014, 09:36

печально то, что в СНГ только 2 нормальные книги на русском: Виталия Поцелуева и Олега Точенюка.
 
далеко нам уже до индусов и остальных - те книги пачками выпускают.

Вы уж простите, я книгу Точенюка не читал. Но я читал его заметки по производительности с сайта sapforum.biz. Могу сказать, что там были моменты, которые, на мой взгляд, являются скорее уж вредными советами. Т.е. модель "дешево и сердито" конечно хороша, но не стоит забывать про "кроилово ведет к попадалову".
Изданная книга это конечно хорошо, но был ли у нее тех.редактор? На примере статей этого ресурса по ABAP, можно сказать, что они не подвергаются рецензированию и редактуре (да какая редактура, если даже орфографические и синтаксические ошибки в статьях не вычищены?)

Комментарий от  

Олег Точенюк

  |  19 ноября 2014, 21:14

Вы уж простите, я книгу Точенюка не читал. Но я читал его заметки по производительности с сайта sapforum.biz. Могу сказать, что там были моменты, которые, на мой взгляд, являются скорее уж вредными советами. Т.е. модель "дешево и сердито" конечно хороша, но не стоит забывать про "кроилово ведет к попадалову".
Изданная книга это конечно хорошо, но был ли у нее тех.редактор? На примере статей этого ресурса по ABAP, можно сказать, что они не подвергаются рецензированию и редактуре (да какая редактура, если даже орфографические и синтаксические ошибки в статьях не вычищены?)

Ну вы их читали, но по факту так ничего в примеры кроме вот этого вот: "являются скорее уж вредными советами" не привели, поэтому беседа как бы ни о чем. Хотя я предложил вам ранее это сделать на конкретных примерах, где по вашему или совет не тот или граната не той системы.
 
По повожу технического редактора, ну я писал, Александры Дублин и Яков Михалыч Басок редактировали, Василий Ковальский вроде как рецензировал, но если для вас это ни о чем не говорит, то фиг с ним, оригинал тоже подойдет, хотя именно это издание я не читал. Но если вы думаете что мне было нечего делать, просто пересказать своими словами приведенную вами ссылку, то я тоже не возражаю.
 
PS: По поводу статей, именно статей тут по абапу их вообще-то мало (кажется 2), вы наверное имеете в виду авторские колонки/блоги. Их конечно же кроме автора вряд ли кто редактирует. Кстати, сделайте свою колонки, а мы почитаем...

Комментарий от  

Олег Точенюк

  |  19 ноября 2014, 21:23

На мой не скромный взгляд: тест по хэшу ни о чем.
1) скорость измерения для хэш-таблы не коррелирует линейно с числом строк в таблице
2) речь идет о микросекундах, т.е. скорее всего это погрешности связанные с накладными расходами на обслуживание работы с таблой собственно, а не на поиск.
3) для чистоты замеров стоит исключить перекладывание найденных данных, использовав вместо INTO конструкцию TRANSPORTING NO FIELDS
4) если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы.
ЗЫ: Непонятно про рекламируемую книгу: зачем она, если есть первоисточники
sap-press.com/abap-performance-tuning_2092

Занятное замечание: "если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы"
 
Вы представляете что такое хеш доступ и как он реализуется при построении индекса? Вообще-то скорость доступа зависит не от длинны ключа (ну если мы не ассемблерный код хеш-функции анализируем и такты процессора с внутренними стеками да длину команд высчитываем), а от качества используемого алгоритма - хеш функции. Чем больше коллизий у алгоритма расчета тем медленнее поиск, так как выполняются различные дополнительные методы обхода коллизий и т.д.
 
PS: Не я понимаю что простое сложение байт строки в 10 символов и строки в 20 выполняется дольше, но мы то про базы данных, а не про что быстрее посчитается на уровне процессора и памяти.

Комментарий от  

Олег Точенюк

  |  19 ноября 2014, 21:26

Ну вы их читали, но по факту так ничего в примеры кроме вот этого вот: "являются скорее уж вредными советами" не привели, поэтому беседа как бы ни о чем. Хотя я предложил вам ранее это сделать на конкретных примерах, где по вашему или совет не тот или граната не той системы.
 
По повожу технического редактора, ну я писал, Александры Дублин и Яков Михалыч Басок редактировали, Василий Ковальский вроде как рецензировал, но если для вас это ни о чем не говорит, то фиг с ним, оригинал тоже подойдет, хотя именно это издание я не читал. Но если вы думаете что мне было нечего делать, просто пересказать своими словами приведенную вами ссылку, то я тоже не возражаю.
 
PS: По поводу статей, именно статей тут по абапу их вообще-то мало (кажется 2), вы наверное имеете в виду авторские колонки/блоги. Их конечно же кроме автора вряд ли кто редактирует. Кстати, сделайте свою колонки, а мы почитаем...

Так извините, нашел переписку, по поводу общения правильно не правильно, это были не вы. Но тем не менее, все равно хотелось бы конструктивных замечаний.

Комментарий от  

Денис Озорнов

  |  20 ноября 2014, 11:27

Занятное замечание: "если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы"
 
Вы представляете что такое хеш доступ и как он реализуется при построении индекса? Вообще-то скорость доступа зависит не от длинны ключа (ну если мы не ассемблерный код хеш-функции анализируем и такты процессора с внутренними стеками да длину команд высчитываем), а от качества используемого алгоритма - хеш функции. Чем больше коллизий у алгоритма расчета тем медленнее поиск, так как выполняются различные дополнительные методы обхода коллизий и т.д.
 
PS: Не я понимаю что простое сложение байт строки в 10 символов и строки в 20 выполняется дольше, но мы то про базы данных, а не про что быстрее посчитается на уровне процессора и памяти.

По поводу хэш функции используемой в сапе в таблице есть тонкость: сап использует какую-то адаптивную функцию с коллизией не более 2 раз(описание попадалось в одном из старых курсов, сейчас не найду, но можно поискать), т.е. : если для хэш ключа есть 2 записи, то ок, если 3 - то они перестраивают таким образом, что бы было только 2 коллизии.
Возможно, что с развитием ядра. алгоритм изменился. Но ранее было так.
Про то что "мы про базу данных" - это вообще чушь. мы как раз не про базы данных, а про то, что выполняется на сервере приложений.

Комментарий от  

Денис Озорнов

  |  20 ноября 2014, 12:28

Ну вы их читали, но по факту так ничего в примеры кроме вот этого вот: "являются скорее уж вредными советами" не привели, поэтому беседа как бы ни о чем. Хотя я предложил вам ранее это сделать на конкретных примерах, где по вашему или совет не тот или граната не той системы.
 
По повожу технического редактора, ну я писал, Александры Дублин и Яков Михалыч Басок редактировали, Василий Ковальский вроде как рецензировал, но если для вас это ни о чем не говорит, то фиг с ним, оригинал тоже подойдет, хотя именно это издание я не читал. Но если вы думаете что мне было нечего делать, просто пересказать своими словами приведенную вами ссылку, то я тоже не возражаю.
 
PS: По поводу статей, именно статей тут по абапу их вообще-то мало (кажется 2), вы наверное имеете в виду авторские колонки/блоги. Их конечно же кроме автора вряд ли кто редактирует. Кстати, сделайте свою колонки, а мы почитаем...

для анализа взята версия 1-2 с сайта
Ну начнем с простого.
1) В файле с советами везде проводится замер производительности на примере таблиц MKPF\MSEG. При этом, говорится о многократном выборе данных из одной и той же таблы, но с разными вариантами параметров. Но нигде не озвучивается, что у БД есть, в общем-то, свой кэш, и что для чистоты замеров кэш надо бы сбрасывать (забивать каким-то мусором, иначе БД будет брать данные из кэша)
2) Цитата со стр 7 "Кстати,
известный факт при использовании довеска «FOR ALL ENTRIES IN», не забываем делать
проверку на наличие данных в таблице, используемой в условии. Потому что, если данных
там нет, то будет выполнен полный проход по таблице выборки, а это плачевно отражается на
скорости выбора данных, даже если вам нужно получить все записи.". Не совсем понятно что понимается в этом случае под таблицей выборки. Проще было написать "при пустой таблице фильтра, будет прочитана полностью таблица СУБД из которой производится выборка"
3) Примеры с чтением таблицы T006A(стр16-18): нигде не указывается что таблица буферизована и в соответствии с этим при джойнах буфер не используется.
4) Стр 19: цитата "При массовых вставках или изменениях данных, не следует использовать COMMIT WORK,
после каждой вставки или изменения данных.". Если до этого были просто замечания, то вот это как раз вредный совет. решение о том, как именно производится коммит\роллбэк принимается на основании бизнес-процесса.  Общего рецепта тут нет и быть не может. Кроме того, стоит помнить, что все изменения логируются в спец. областях СУБД до своей фиксаци в БД. если выполнять длинную транзакцию БД (или LUW если угодно использовать терминологию SAP), то есть все шансы нарваться на переполнение rollback segment\transaction log
5) не менее шикарно смотрится рассуждение с 19 по 25 страницу, о том как после коммита ловить факт создания объекта. Скажите, а почему просто не используется синхронное обновление с использованием COMMIT WORK AND WAIT? Ведь, согласно хелпу, как раз в этом случае программа будет гарантировано ждать, когда же объекты доедут в БД.
Я могу искать и дальше, но я не буду этого делать по той же причине почему не буду вести здсь блог\колонку: мне за это не платят зарплату.

Комментарий от  

Денис Озорнов

  |  21 ноября 2014, 09:49

Занятное замечание: "если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы"
 
Вы представляете что такое хеш доступ и как он реализуется при построении индекса? Вообще-то скорость доступа зависит не от длинны ключа (ну если мы не ассемблерный код хеш-функции анализируем и такты процессора с внутренними стеками да длину команд высчитываем), а от качества используемого алгоритма - хеш функции. Чем больше коллизий у алгоритма расчета тем медленнее поиск, так как выполняются различные дополнительные методы обхода коллизий и т.д.
 
PS: Не я понимаю что простое сложение байт строки в 10 символов и строки в 20 выполняется дольше, но мы то про базы данных, а не про что быстрее посчитается на уровне процессора и памяти.

Собственно вот цитата из курса BC402 (версия 2006 Q2, страница 200) про то, какой алгоритм используется для хэш-таблиц.
Access to a hashed table is implemented using a hash algorithm. Simplified, this
means that the data records are distributed randomly but evenly over a particular
memory area. The addresses are saved in a separate table, the hashed table. To
do this, a hash function uses the key data to calculate an address where the hashed
table entry can be found.
The function is not injective, that is, there can be two data records stored at a single
address. This is implemented internally as a chained list. Therefore, the system may
have to perform a sequential search within this type of area. However, the chained list
can only contain a maximum of two entries. If the same hash table address results
for a third new key, the system uses a changed hash function and rebuilds the entire
management area. The graphic illustrates the simplest case, in which only one record
is stored at each address.

Комментарий от  

Олег Точенюк

  |  22 ноября 2014, 16:27

Собственно вот цитата из курса BC402 (версия 2006 Q2, страница 200) про то, какой алгоритм используется для хэш-таблиц.
Access to a hashed table is implemented using a hash algorithm. Simplified, this
means that the data records are distributed randomly but evenly over a particular
memory area. The addresses are saved in a separate table, the hashed table. To
do this, a hash function uses the key data to calculate an address where the hashed
table entry can be found.
The function is not injective, that is, there can be two data records stored at a single
address. This is implemented internally as a chained list. Therefore, the system may
have to perform a sequential search within this type of area. However, the chained list
can only contain a maximum of two entries. If the same hash table address results
for a third new key, the system uses a changed hash function and rebuilds the entire
management area. The graphic illustrates the simplest case, in which only one record
is stored at each address.

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

Комментарий от  

Олег Точенюк

  |  22 ноября 2014, 17:14

для анализа взята версия 1-2 с сайта
Ну начнем с простого.
1) В файле с советами везде проводится замер производительности на примере таблиц MKPF\MSEG. При этом, говорится о многократном выборе данных из одной и той же таблы, но с разными вариантами параметров. Но нигде не озвучивается, что у БД есть, в общем-то, свой кэш, и что для чистоты замеров кэш надо бы сбрасывать (забивать каким-то мусором, иначе БД будет брать данные из кэша)
2) Цитата со стр 7 "Кстати,
известный факт при использовании довеска «FOR ALL ENTRIES IN», не забываем делать
проверку на наличие данных в таблице, используемой в условии. Потому что, если данных
там нет, то будет выполнен полный проход по таблице выборки, а это плачевно отражается на
скорости выбора данных, даже если вам нужно получить все записи.". Не совсем понятно что понимается в этом случае под таблицей выборки. Проще было написать "при пустой таблице фильтра, будет прочитана полностью таблица СУБД из которой производится выборка"
3) Примеры с чтением таблицы T006A(стр16-18): нигде не указывается что таблица буферизована и в соответствии с этим при джойнах буфер не используется.
4) Стр 19: цитата "При массовых вставках или изменениях данных, не следует использовать COMMIT WORK,
после каждой вставки или изменения данных.". Если до этого были просто замечания, то вот это как раз вредный совет. решение о том, как именно производится коммит\роллбэк принимается на основании бизнес-процесса.  Общего рецепта тут нет и быть не может. Кроме того, стоит помнить, что все изменения логируются в спец. областях СУБД до своей фиксаци в БД. если выполнять длинную транзакцию БД (или LUW если угодно использовать терминологию SAP), то есть все шансы нарваться на переполнение rollback segment\transaction log
5) не менее шикарно смотрится рассуждение с 19 по 25 страницу, о том как после коммита ловить факт создания объекта. Скажите, а почему просто не используется синхронное обновление с использованием COMMIT WORK AND WAIT? Ведь, согласно хелпу, как раз в этом случае программа будет гарантировано ждать, когда же объекты доедут в БД.
Я могу искать и дальше, но я не буду этого делать по той же причине почему не буду вести здсь блог\колонку: мне за это не платят зарплату.

1) В файле с советами везде проводится замер производительности на примере таблиц MKPF\MSEG.
 
Ну на самом деле замеры проводились не на одной системе, на разных конфигурациях, короче где был доступ там и гонял программки. Технически после запросов делался  SELECT * FROM <таблица>, типа а прочитайка всю таблицу снова. Вообще-то в документе и книжке представлялись результаты, а не методики измерений. Так что это, как мне кажется, замечание по тому чего в документе нет :-)
 
2. В книге про "FOR ALL ENTRIES" формулировка почти такая же, с парой тестовых примеров при пустой таблицы в условии. Возможно ваше замечание и упрощает формулировку, но кроме вас никто не написал об этом.
 
3. Ну что в JOIN не используется буферизация по тексту есть отдельное замечание в разделе работы с буферизированными таблицами. Вообще-то буферизацию можно отключать/включать, хотя конечно проблемы при таких операциях могут быть уже вашими, о чем SAP собственного говоря и предупреждает.
 
4. Ну почему же, вот вы считаете что общего рецепта нет, я считают что он есть. Замечание касалось массовой заливки/обновления данных в системе. Переполнить транзакшин лог? Но, как раз данное замечание и касалось того, что нужно выполнять периодические промежуточные фиксации результатов работы. Делать это после каждого обработанного объекта, страдает производительность, делать это в конце обработки всех объектов, тоже страдает производительность + технические проблемы журнала транзакции. Поэтому там ровно сказано то, что периодически фиксируйте ваши изменения. Рецепт фиксации мой, чисто опытный. Если правильно помню, то там же сказано, что в каждом случае нужно смотреть на что обновляется и как.
 
5. Ну вот этот пункт это не у меня "шикарно", это у вас "шикарно", я бы данное замечание приводил как яркую иллюстрация к фразе зачем нужны книги русском и пользе чтения английских текстов. Вы вот сослались на справку, она по абапу на английском, вот только проблема в том, что вы прочитав, подумали что поняли все правильно. По факту же, вы абсолютно не поняли разницы между синхронными и асинхронным коммитом (в книге на русском я таки это описал более развернуто чем в документе с форума). Данный вывод я делаю по вашей фразе "программа будет гарантировано ждать, когда же объекты доедут в БД". Так вот синхронный коммит не будет ждать, пока объекты куда-то доедут, он просто подождет выполнения модулей/подпрограмм обновления и ВСЕ! Последующее чтение после выполнения синхронного коммита периодические будет выдавать сообщение об отсутствии записи в базе данных. Вариантов обхода этой ситуации много, я поделился тем, который для себя определил как самый быстрый при массовой вставке объектов в БД, при условии, что последующий объект ссылается на предыдущий.
 

И в завершении "почему не буду вести здсь блог\колонку: мне за это не платят зарплату" - Ну это вам к Дублину, он на такие темы любит объяснить кто и где заблуждается :-)

Комментарий от  

Олег Точенюк

  |  22 ноября 2014, 17:31

печально то, что в СНГ только 2 нормальные книги на русском: Виталия Поцелуева и Олега Точенюка.
 
далеко нам уже до индусов и остальных - те книги пачками выпускают.

Ну вообще-то их три, третья по BPC от Михаил Савкин: sapland.ru/books/avtomatizatsiya-protsessov-v-sap-businessobjects-planning-and-consolidation-funk.html

Комментарий от  

Денис Озорнов

  |  22 ноября 2014, 21:42

1) В файле с советами везде проводится замер производительности на примере таблиц MKPF\MSEG.
 
Ну на самом деле замеры проводились не на одной системе, на разных конфигурациях, короче где был доступ там и гонял программки. Технически после запросов делался  SELECT * FROM <таблица>, типа а прочитайка всю таблицу снова. Вообще-то в документе и книжке представлялись результаты, а не методики измерений. Так что это, как мне кажется, замечание по тому чего в документе нет :-)
 
2. В книге про "FOR ALL ENTRIES" формулировка почти такая же, с парой тестовых примеров при пустой таблицы в условии. Возможно ваше замечание и упрощает формулировку, но кроме вас никто не написал об этом.
 
3. Ну что в JOIN не используется буферизация по тексту есть отдельное замечание в разделе работы с буферизированными таблицами. Вообще-то буферизацию можно отключать/включать, хотя конечно проблемы при таких операциях могут быть уже вашими, о чем SAP собственного говоря и предупреждает.
 
4. Ну почему же, вот вы считаете что общего рецепта нет, я считают что он есть. Замечание касалось массовой заливки/обновления данных в системе. Переполнить транзакшин лог? Но, как раз данное замечание и касалось того, что нужно выполнять периодические промежуточные фиксации результатов работы. Делать это после каждого обработанного объекта, страдает производительность, делать это в конце обработки всех объектов, тоже страдает производительность + технические проблемы журнала транзакции. Поэтому там ровно сказано то, что периодически фиксируйте ваши изменения. Рецепт фиксации мой, чисто опытный. Если правильно помню, то там же сказано, что в каждом случае нужно смотреть на что обновляется и как.
 
5. Ну вот этот пункт это не у меня "шикарно", это у вас "шикарно", я бы данное замечание приводил как яркую иллюстрация к фразе зачем нужны книги русском и пользе чтения английских текстов. Вы вот сослались на справку, она по абапу на английском, вот только проблема в том, что вы прочитав, подумали что поняли все правильно. По факту же, вы абсолютно не поняли разницы между синхронными и асинхронным коммитом (в книге на русском я таки это описал более развернуто чем в документе с форума). Данный вывод я делаю по вашей фразе "программа будет гарантировано ждать, когда же объекты доедут в БД". Так вот синхронный коммит не будет ждать, пока объекты куда-то доедут, он просто подождет выполнения модулей/подпрограмм обновления и ВСЕ! Последующее чтение после выполнения синхронного коммита периодические будет выдавать сообщение об отсутствии записи в базе данных. Вариантов обхода этой ситуации много, я поделился тем, который для себя определил как самый быстрый при массовой вставке объектов в БД, при условии, что последующий объект ссылается на предыдущий.
 

И в завершении "почему не буду вести здсь блог\колонку: мне за это не платят зарплату" - Ну это вам к Дублину, он на такие темы любит объяснить кто и где заблуждается :-)

По пордяку:
1) про чтение той же таблицы всей целиком. Эта операция сделает вам в кэше как раз данные из той же таблы, что не вариант для очистки кэша.
 
2) про массовые операции: даже массовые операции зависят от бизнес процесса. Поэтому первое пожелание во всех подобных действах: определитесь, что вы хотите делать с точки зрения бизнеса.
3) По поводу синхронного апдейта, с вами не согласен хелп сапа, цитата
In synchronous update, you do not submit update requests using CALL FUNCTION … IN UPDATE TASK . Instead you use the ABAP statement COMMIT WORK AND WAIT. When the update is finished, control passes back to the program.
Пруф: help.sap.com/saphelp_nw70/helpdata

Комментарий от  

Александр Дублин

  |  23 ноября 2014, 00:55

Вы уж простите, я книгу Точенюка не читал. Но я читал его заметки по производительности с сайта sapforum.biz. Могу сказать, что там были моменты, которые, на мой взгляд, являются скорее уж вредными советами. Т.е. модель "дешево и сердито" конечно хороша, но не стоит забывать про "кроилово ведет к попадалову".
Изданная книга это конечно хорошо, но был ли у нее тех.редактор? На примере статей этого ресурса по ABAP, можно сказать, что они не подвергаются рецензированию и редактуре (да какая редактура, если даже орфографические и синтаксические ошибки в статьях не вычищены?)

Так почитайте :-)

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 01:09

По пордяку:
1) про чтение той же таблицы всей целиком. Эта операция сделает вам в кэше как раз данные из той же таблы, что не вариант для очистки кэша.
 
2) про массовые операции: даже массовые операции зависят от бизнес процесса. Поэтому первое пожелание во всех подобных действах: определитесь, что вы хотите делать с точки зрения бизнеса.
3) По поводу синхронного апдейта, с вами не согласен хелп сапа, цитата
In synchronous update, you do not submit update requests using CALL FUNCTION … IN UPDATE TASK . Instead you use the ABAP statement COMMIT WORK AND WAIT. When the update is finished, control passes back to the program.
Пруф: help.sap.com/saphelp_nw70/helpdata

1. Ну это у вас какие-то упрощенные представления о методике кеширования записей на уровне СУБД. Не хана же, все в память затаскивать. Да и еще раз, тестирование проводилось на разных системах с разной загрузкой и это усредненные числа. Можете предложить свои варианты расчета производительности, хотя конечно вам за это ж не заплатят, поэтому вряд ли.
 
2. Да какие там нафиг бизнес процессы то? Есть объект, надо обновить данные, есть BAPI, нет BAPI смотрим что есть и выполняем задачу. Зачем же усложнять и так сложное.
 
3. Ну вот я и говорю, что прочитать вы прочитали, да только не поняли что. Вот и думаете, что синхронный апдейт вам обещает обновление на уровне БД, хотя там такого нет, но вы то прочитали и поняли так как поняли.

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 01:37

1. Ну это у вас какие-то упрощенные представления о методике кеширования записей на уровне СУБД. Не хана же, все в память затаскивать. Да и еще раз, тестирование проводилось на разных системах с разной загрузкой и это усредненные числа. Можете предложить свои варианты расчета производительности, хотя конечно вам за это ж не заплатят, поэтому вряд ли.
 
2. Да какие там нафиг бизнес процессы то? Есть объект, надо обновить данные, есть BAPI, нет BAPI смотрим что есть и выполняем задачу. Зачем же усложнять и так сложное.
 
3. Ну вот я и говорю, что прочитать вы прочитали, да только не поняли что. Вот и думаете, что синхронный апдейт вам обещает обновление на уровне БД, хотя там такого нет, но вы то прочитали и поняли так как поняли.

1) Методику кеширования например оракла я знаю, это LRU алгоритм. Вам знакомо такое понятие? Т.е.'least recently used'. Т.е. вытеснение менее нужных данных при заполнении кэша, см. например docs.oracle.com/cd/B28359_01
И не надо приплетать хану. Есть некий объем кэша. Читаем больше чем есть в нем места? происходит вытеснение  реже читаемых данных из кэша.
2) Какие? да например те же самые, что вы описывает, когда пытаетесь через чтение блокировок поймать ранее созданный документ\запись справочника и т.д.
3) Ну если для вас мало синхронного апдейта, несмотря на вполне исчерпывающее описание (зря не потрудились прочитать, там сказано, что вольется именно в базу, если не используете апдейт таск модули, а есть и такие BAPI), то есть еще и LOCAL UPDATE. Вот в них уже даже апдейт таски выполняются в том же процессе. Или вы опять буде спорить с хелпом сапа?

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 09:55

1. Ну это у вас какие-то упрощенные представления о методике кеширования записей на уровне СУБД. Не хана же, все в память затаскивать. Да и еще раз, тестирование проводилось на разных системах с разной загрузкой и это усредненные числа. Можете предложить свои варианты расчета производительности, хотя конечно вам за это ж не заплатят, поэтому вряд ли.
 
2. Да какие там нафиг бизнес процессы то? Есть объект, надо обновить данные, есть BAPI, нет BAPI смотрим что есть и выполняем задачу. Зачем же усложнять и так сложное.
 
3. Ну вот я и говорю, что прочитать вы прочитали, да только не поняли что. Вот и думаете, что синхронный апдейт вам обещает обновление на уровне БД, хотя там такого нет, но вы то прочитали и поняли так как поняли.

Кстати, пожалуйста, изложите ваше толкование того, что изложено в хелпе. Только пожалуйста, каждую вашу сентенцию снабдите ссылкой на цитату из хелпа. Пока что, вы только голословно утверждаете, что мое понимании не верно, не смотря на приложенную однозначно трактуемую цитату из документации. Как мне кажется, документация в этом случае все определяет  однозначно. Развейте-таки мои сомнения!

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 13:39

1) Методику кеширования например оракла я знаю, это LRU алгоритм. Вам знакомо такое понятие? Т.е.'least recently used'. Т.е. вытеснение менее нужных данных при заполнении кэша, см. например docs.oracle.com/cd/B28359_01
И не надо приплетать хану. Есть некий объем кэша. Читаем больше чем есть в нем места? происходит вытеснение  реже читаемых данных из кэша.
2) Какие? да например те же самые, что вы описывает, когда пытаетесь через чтение блокировок поймать ранее созданный документ\запись справочника и т.д.
3) Ну если для вас мало синхронного апдейта, несмотря на вполне исчерпывающее описание (зря не потрудились прочитать, там сказано, что вольется именно в базу, если не используете апдейт таск модули, а есть и такие BAPI), то есть еще и LOCAL UPDATE. Вот в них уже даже апдейт таски выполняются в том же процессе. Или вы опять буде спорить с хелпом сапа?

1. Замечательно что вы ее знаете, т.е. вы предполагаете что кеша хватит на полную заливку таблицы MSEG в память, путем удаления вообще всего ранее считанного? Не ну думайте так дальше.
 
2. Ну это вы решили тут совместить написанное в двух разных местах. А в описании есть отдельно процесс массового обновления объектов и процесс определения наличия объекта в БД, в данном случае через блокировку.
 
3. Для меня конечно мало, мне как вы говорите зарплату не платят чтобы разжевывать вам перевод справки системы, который вы не очень понимаете. Так что дальше будьте уверены что синхронного апдейта и включенного локального обновления вам будет достаточно для появления объекта в БД.

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 13:44

Кстати, пожалуйста, изложите ваше толкование того, что изложено в хелпе. Только пожалуйста, каждую вашу сентенцию снабдите ссылкой на цитату из хелпа. Пока что, вы только голословно утверждаете, что мое понимании не верно, не смотря на приложенную однозначно трактуемую цитату из документации. Как мне кажется, документация в этом случае все определяет  однозначно. Развейте-таки мои сомнения!

Зачем вам цитаты из хелпа? Вы их уже привели, но вы их не очень понимаете судя по всему. Толкование расписано в книге, ну вам то она не нужна, а переписывать сюда то что там уже написано, как то не вижу смысла.
 
PS: Да и это не толкование, это фактическая проверка того как это работает. Тоже в свое время свято верил что синхронный апдейт гарантирует появления объекта на уровне БД. Пока не понял как же это по факту работает. Будет время можете проверить, программка пишется быстро, а вот результат вас я думаю немного озадачит. Можете там покомбинировать синхронный/асинхронные апдейты, локальное обновление и т.д.

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 14:42

Зачем вам цитаты из хелпа? Вы их уже привели, но вы их не очень понимаете судя по всему. Толкование расписано в книге, ну вам то она не нужна, а переписывать сюда то что там уже написано, как то не вижу смысла.
 
PS: Да и это не толкование, это фактическая проверка того как это работает. Тоже в свое время свято верил что синхронный апдейт гарантирует появления объекта на уровне БД. Пока не понял как же это по факту работает. Будет время можете проверить, программка пишется быстро, а вот результат вас я думаю немного озадачит. Можете там покомбинировать синхронный/асинхронные апдейты, локальное обновление и т.д.

Т.е. ваш слив защитан? Привести цитату из хелпа вы не можете. Все остальное - ваши измышления?

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 14:46

1. Замечательно что вы ее знаете, т.е. вы предполагаете что кеша хватит на полную заливку таблицы MSEG в память, путем удаления вообще всего ранее считанного? Не ну думайте так дальше.
 
2. Ну это вы решили тут совместить написанное в двух разных местах. А в описании есть отдельно процесс массового обновления объектов и процесс определения наличия объекта в БД, в данном случае через блокировку.
 
3. Для меня конечно мало, мне как вы говорите зарплату не платят чтобы разжевывать вам перевод справки системы, который вы не очень понимаете. Так что дальше будьте уверены что синхронного апдейта и включенного локального обновления вам будет достаточно для появления объекта в БД.

1) Кажется вы не понимаете суть алгоритма LRU. Объясню. Если вы делаете пример на mseg, а потом делаете его же полное перечитывание что бы забить кэш, то на выходе есть не нулевая вероятность, что в кэше остануться те же данные, на которых вы тестируете. И это будет вне зависимости от размера кэша БД. Как-то так.
2) Да. именно. Не бывает сферических коней в вакууме. Задача вполне утилитарна. И совет в данном случае не покрывает всего поля возможностей
3) Как я вижу хелп и курсы вы не примаете как аргумент. Адекватного аргумента не приводите, кроме голословных утверждений "я знаю" и рекламы вашего опуса. Я, например потрудился и прочел хотя бы часть вашего труда на форуме и высказал вполне обоснованные сомнения в его адекватности. Опровергнуть вы их не можете. Как говорили математики: ЧТД.

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 18:50

1) Кажется вы не понимаете суть алгоритма LRU. Объясню. Если вы делаете пример на mseg, а потом делаете его же полное перечитывание что бы забить кэш, то на выходе есть не нулевая вероятность, что в кэше остануться те же данные, на которых вы тестируете. И это будет вне зависимости от размера кэша БД. Как-то так.
2) Да. именно. Не бывает сферических коней в вакууме. Задача вполне утилитарна. И совет в данном случае не покрывает всего поля возможностей
3) Как я вижу хелп и курсы вы не примаете как аргумент. Адекватного аргумента не приводите, кроме голословных утверждений "я знаю" и рекламы вашего опуса. Я, например потрудился и прочел хотя бы часть вашего труда на форуме и высказал вполне обоснованные сомнения в его адекватности. Опровергнуть вы их не можете. Как говорили математики: ЧТД.

1. Не вопрос. Про сферический кэш СУБД убедили, он бесконечный и в нем все остается.
 
2. Не вопрос, как раза если задача утилитарная, то и опыт ее экстраполируется на другие утилитарные задачи. Этот опыт и рекомендации и описаны. Применять их или нет, ваше право.
 
3. Тоже не вопрос, пребывайте и дальше в своих заблуждениях, опровергается это очень просто тестовым примером, минут за 30. Проводка документов ММ через стандартную BAPI, с последующим чтением проведенного документа. Что и описано в примерах. Для вас это не убедительно, опять же ваше право. Я это проверил практически, вы чисто теоретически прочитав английский курс/справку и не поняв что там написано, пытаетесь меня убедить в обратном. Ну тоже не вопрос, считайте и дальше что вы правильно поняли написанное в курсе/справке.

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 18:50

Т.е. ваш слив защитан? Привести цитату из хелпа вы не можете. Все остальное - ваши измышления?

Ну зачем же мне приводить вашу же ссылку. Ссылка правильная, а вот что в ней написано вы понимаете не правильно. Оставайтесь в своем заблуждении и далее.

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 18:55

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

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 20:09

1. Не вопрос. Про сферический кэш СУБД убедили, он бесконечный и в нем все остается.
 
2. Не вопрос, как раза если задача утилитарная, то и опыт ее экстраполируется на другие утилитарные задачи. Этот опыт и рекомендации и описаны. Применять их или нет, ваше право.
 
3. Тоже не вопрос, пребывайте и дальше в своих заблуждениях, опровергается это очень просто тестовым примером, минут за 30. Проводка документов ММ через стандартную BAPI, с последующим чтением проведенного документа. Что и описано в примерах. Для вас это не убедительно, опять же ваше право. Я это проверил практически, вы чисто теоретически прочитав английский курс/справку и не поняв что там написано, пытаетесь меня убедить в обратном. Ну тоже не вопрос, считайте и дальше что вы правильно поняли написанное в курсе/справке.

1) Еще раз. Не бесконечный кэш. В кэше остаются данные которые читаются чаще всего. Прочитали строку А при поиске с индексом 5 раз - Она осталась в кэше. прочитали ту же строку но с поиском в фуллскане - она все равно останется, как часто читаемая.
3) Т.е. так и записываем объяснить что же я не правильно понял в хелпе - вы не можете.

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 20:09

Ну зачем же мне приводить вашу же ссылку. Ссылка правильная, а вот что в ней написано вы понимаете не правильно. Оставайтесь в своем заблуждении и далее.

Т.е. ответить на вопрос "что же именно я понял не правильно?" вы не в состоянии? Ок. Так и зафиксируем. Объяснить - не способны.

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 20:21

1. Не вопрос. Про сферический кэш СУБД убедили, он бесконечный и в нем все остается.
 
2. Не вопрос, как раза если задача утилитарная, то и опыт ее экстраполируется на другие утилитарные задачи. Этот опыт и рекомендации и описаны. Применять их или нет, ваше право.
 
3. Тоже не вопрос, пребывайте и дальше в своих заблуждениях, опровергается это очень просто тестовым примером, минут за 30. Проводка документов ММ через стандартную BAPI, с последующим чтением проведенного документа. Что и описано в примерах. Для вас это не убедительно, опять же ваше право. Я это проверил практически, вы чисто теоретически прочитав английский курс/справку и не поняв что там написано, пытаетесь меня убедить в обратном. Ну тоже не вопрос, считайте и дальше что вы правильно поняли написанное в курсе/справке.

И это я еще не упомянул про ваш вредный совет использовать установку-снятие блокировки, вместо простого вызова ENQUEUE_READ

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 20:25

И это я еще не упомянул про ваш вредный совет использовать установку-снятие блокировки, вместо простого вызова ENQUEUE_READ

Ну что вам сказать... с чего вы решили что блокировка на создаваемый объект будет в буфере блокирования при создании записи? В справке прочитали? А при изменении, ну замерьте что быстрее будет установка/снятие блокировки или чтение таблицы? Вы кстати ее как читать будете? В цикле пока там запись не пропадет? Успехов... так сказать.

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 20:33

1) Еще раз. Не бесконечный кэш. В кэше остаются данные которые читаются чаще всего. Прочитали строку А при поиске с индексом 5 раз - Она осталась в кэше. прочитали ту же строку но с поиском в фуллскане - она все равно останется, как часто читаемая.
3) Т.е. так и записываем объяснить что же я не правильно понял в хелпе - вы не можете.

1. А с чего вы решили что я там в примерах да еще на разных системах, с разным количеством пользователей, а записи точно в кэще будут, потому что они наиболее частыми оказались? Не ну опять же не вопрос, теоретизируйте дальше, у меня практические выкладки и проверены они на разных системах с разными интервалами выполнения запросов. Но для вас это ни что. Я вообще-то вас не убеждаю.
 
3. Ну выражаясь вашими словами, мне за это лично вы не платите,поэтому не очень понимаю почему я вам обязан что-то объяснять так чтобы вы именно поняли. Я и так достаточно за бесплатно вас проконсультировал, вы считаете что я пишу ерунду, еще десяток людей который участвовали в написании книги тоже несут пургу. Ну дальше как бы смысла продолжать. Кстати про описанную ниже функцию чтения записей блокирования для проверки объектов, это пять... вы даже не очень понимаете сами что предлагаете, ну да это не важно вы же я так понял прожженный абапер. Любитель циклических вызовов разных ФМ-ов. Не возражаю, пишите и дальше в таком же духе. Да в и вообще оптимизация вещь вредная, кому не хватает купят сервер по мощнее, базу побыстрее и т.д.

Комментарий от  

Олег Точенюк

  |  23 ноября 2014, 20:35

Т.е. ответить на вопрос "что же именно я понял не правильно?" вы не в состоянии? Ок. Так и зафиксируем. Объяснить - не способны.

За бесплатно - лично для вас НЕТ. Учите английский и матчасть. Сторону копания я вам указал, дальше вопрос закрыт :-)

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 20:39

Ну что вам сказать... с чего вы решили что блокировка на создаваемый объект будет в буфере блокирования при создании записи? В справке прочитали? А при изменении, ну замерьте что быстрее будет установка/снятие блокировки или чтение таблицы? Вы кстати ее как читать будете? В цикле пока там запись не пропадет? Успехов... так сказать.

Читать что? Вы не знаете как хранятся блокировки в базе? Это стандартный модуль почтению блокировки. Он работает быстрее чем 2 операции: установка и снятие. Замерьте уже тем самым se30 и sat

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 20:41

1. А с чего вы решили что я там в примерах да еще на разных системах, с разным количеством пользователей, а записи точно в кэще будут, потому что они наиболее частыми оказались? Не ну опять же не вопрос, теоретизируйте дальше, у меня практические выкладки и проверены они на разных системах с разными интервалами выполнения запросов. Но для вас это ни что. Я вообще-то вас не убеждаю.
 
3. Ну выражаясь вашими словами, мне за это лично вы не платите,поэтому не очень понимаю почему я вам обязан что-то объяснять так чтобы вы именно поняли. Я и так достаточно за бесплатно вас проконсультировал, вы считаете что я пишу ерунду, еще десяток людей который участвовали в написании книги тоже несут пургу. Ну дальше как бы смысла продолжать. Кстати про описанную ниже функцию чтения записей блокирования для проверки объектов, это пять... вы даже не очень понимаете сами что предлагаете, ну да это не важно вы же я так понял прожженный абапер. Любитель циклических вызовов разных ФМ-ов. Не возражаю, пишите и дальше в таком же духе. Да в и вообще оптимизация вещь вредная, кому не хватает купят сервер по мощнее, базу побыстрее и т.д.

Я попробовал предлагаемый вами пример чтения из MKPF после создания документа ММ. У меня все прочиталось согласно хелпу по commit work and wait. Что я делаю не так?

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 20:47

Ну что вам сказать... с чего вы решили что блокировка на создаваемый объект будет в буфере блокирования при создании записи? В справке прочитали? А при изменении, ну замерьте что быстрее будет установка/снятие блокировки или чтение таблицы? Вы кстати ее как читать будете? В цикле пока там запись не пропадет? Успехов... так сказать.

На создаваемый - естественно не будет.
И кстати говоря, я совершенно спокойно могу ставить блокировки на не существующий в базе объект.
И соответственно у вас опять в мануале чушь написана: вы предлагаете с помощью установки блока проверить, а создался ли этот док, при том, что при его создании как раз блокировки не будет вообще, а система на не существующие номера блокировки ставить позволяет.
Для хранения блокировок и их чтения\записи используются си-щные функции ядра. Поэтому БД там не читается. Вам исходник приведенного мной ФМ кинуть, если вы не в силах его посмотреть в системе сами?

Комментарий от  

Денис Озорнов

  |  23 ноября 2014, 20:59

1. А с чего вы решили что я там в примерах да еще на разных системах, с разным количеством пользователей, а записи точно в кэще будут, потому что они наиболее частыми оказались? Не ну опять же не вопрос, теоретизируйте дальше, у меня практические выкладки и проверены они на разных системах с разными интервалами выполнения запросов. Но для вас это ни что. Я вообще-то вас не убеждаю.
 
3. Ну выражаясь вашими словами, мне за это лично вы не платите,поэтому не очень понимаю почему я вам обязан что-то объяснять так чтобы вы именно поняли. Я и так достаточно за бесплатно вас проконсультировал, вы считаете что я пишу ерунду, еще десяток людей который участвовали в написании книги тоже несут пургу. Ну дальше как бы смысла продолжать. Кстати про описанную ниже функцию чтения записей блокирования для проверки объектов, это пять... вы даже не очень понимаете сами что предлагаете, ну да это не важно вы же я так понял прожженный абапер. Любитель циклических вызовов разных ФМ-ов. Не возражаю, пишите и дальше в таком же духе. Да в и вообще оптимизация вещь вредная, кому не хватает купят сервер по мощнее, базу побыстрее и т.д.

Про кэш.Я пытался на таком простом примере показать качество вашего текста. Вы не описываете условия проведения примеров. Есть научный метод(погуглите что ли): полностью описывайте условия эксперимента, что бы при воспроизведении в др. лабах сходились его результаты.
 
Т.е. все в итоге как и остальное у вас "хелп не правильный, я знаю лучше". Ок. знайте. Только другим не надо впаривать свои кривые знания. Я думаю, те кто читали эту дискуссию все про вас поняли. От вас не поступило ни одного потвержденного документацией  аргумента, только хамство в итоге

Комментарий от  

Олег Точенюк

  |  24 ноября 2014, 01:22

На создаваемый - естественно не будет.
И кстати говоря, я совершенно спокойно могу ставить блокировки на не существующий в базе объект.
И соответственно у вас опять в мануале чушь написана: вы предлагаете с помощью установки блока проверить, а создался ли этот док, при том, что при его создании как раз блокировки не будет вообще, а система на не существующие номера блокировки ставить позволяет.
Для хранения блокировок и их чтения\записи используются си-щные функции ядра. Поэтому БД там не читается. Вам исходник приведенного мной ФМ кинуть, если вы не в силах его посмотреть в системе сами?

Убедили ставьте. Устал знаете ли, поэтому ушел.

Комментарий от  

Александр Дублин

  |  24 ноября 2014, 11:27

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

"Я Пастернака не читал, но осуждаю...
...
И как мать, и как женщина ...."

Комментарий от  

Денис Озорнов

  |  24 ноября 2014, 16:28

За бесплатно - лично для вас НЕТ. Учите английский и матчасть. Сторону копания я вам указал, дальше вопрос закрыт :-)

Это я за просто так вывел косяки в вашей заметке. Вы же на это не смогли привести ни одного аргумента.
1) Вы так и не сказали , в каком месте я не правильно прочитал хелп, упомянув при этом что "место правильное, но понимаю я его не правильно"
2) пример из вашей статьи я воспроизвел с COMMIT WORK AND WAIT. Все работает как часы согласно хелпа.
3) вы сделали выводы о том как я работаю , приписав мне слова, которых я не говорил (начиная о сферических кэшах(при том, что я дал ссылку на конкретную статью об оракле) и заканчивая выводами о моем стиле программирования, при том что не видели не единой строки моего кода)
4) Чего стоит ваш пассаж ниже в камменте о хэш-табле, когда вы как-то незаметно начинаете говорить о БД, не смотря на то что речь шла именно о хэш-табле, т.е. объекте которого в БД просто нет.
 
Прекрасный показатель вашего уровня дискуссий и ваших статей\книг и лекций.
 
PS: по поводу отсылки к Василию Ковальскому: я вообще в экстазе. Так и представляю, как Василий, читая курс BC414 на космодаминской набережной, долго рассказывает то, как изложено в хелпе и курсе, а потом на вопрос слушателя "А вот Точенюк в своей книге и статьях говорит, что  синхронное обновление в хелпе определено не верно" удивленно смотрит на вопрошающего.
Ага.

Комментарий от  

Олег Точенюк

  |  25 ноября 2014, 00:12

Это я за просто так вывел косяки в вашей заметке. Вы же на это не смогли привести ни одного аргумента.
1) Вы так и не сказали , в каком месте я не правильно прочитал хелп, упомянув при этом что "место правильное, но понимаю я его не правильно"
2) пример из вашей статьи я воспроизвел с COMMIT WORK AND WAIT. Все работает как часы согласно хелпа.
3) вы сделали выводы о том как я работаю , приписав мне слова, которых я не говорил (начиная о сферических кэшах(при том, что я дал ссылку на конкретную статью об оракле) и заканчивая выводами о моем стиле программирования, при том что не видели не единой строки моего кода)
4) Чего стоит ваш пассаж ниже в камменте о хэш-табле, когда вы как-то незаметно начинаете говорить о БД, не смотря на то что речь шла именно о хэш-табле, т.е. объекте которого в БД просто нет.
 
Прекрасный показатель вашего уровня дискуссий и ваших статей\книг и лекций.
 
PS: по поводу отсылки к Василию Ковальскому: я вообще в экстазе. Так и представляю, как Василий, читая курс BC414 на космодаминской набережной, долго рассказывает то, как изложено в хелпе и курсе, а потом на вопрос слушателя "А вот Точенюк в своей книге и статьях говорит, что  синхронное обновление в хелпе определено не верно" удивленно смотрит на вопрошающего.
Ага.

2. Код в студию, что вы и как проверяли. Если боитесь за авторство схематично блоки кода.

Комментарий от  

Денис Озорнов

  |  25 ноября 2014, 11:57

2. Код в студию, что вы и как проверяли. Если боитесь за авторство схематично блоки кода.

Тестовый пример, исключительно для иллюстрации,  создает движение ММ, после чего проверяет наличие созданного документа в MKPF.
Привожу пример с асинхронным сохранением, опустив заполнение параметров BAPI. В таком виде выдает  результат "не ок". При замене на commit work and wait - выдает ok.
 
  CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
    EXPORTING
      goodsmvt_header  = lmmdocheader
      goodsmvt_code    = lgmcode
      testrun          = abap_false
    IMPORTING
      goodsmvt_headret = lmmdocheader_ret
      materialdocument = lmblnr
      matdocumentyear  = lmjahr
    TABLES
      goodsmvt_item    = lt_mmdocitems
      return           = lt_bapiret.
 

  COMMIT WORK.
 
  SELECT SINGLE *
    INTO mkpf
    FROM mkpf
    WHERE mblnr = lmblnr.
 
  IF sy-subrc = 0.
    WRITE: / 'ok'.
  ELSE.
    WRITE: / 'не ok'.
  ENDIF.
 
WRITE:/ lmblnr.

Комментарий от  

Денис Озорнов

  |  25 ноября 2014, 12:21

Тестовый пример, исключительно для иллюстрации,  создает движение ММ, после чего проверяет наличие созданного документа в MKPF.
Привожу пример с асинхронным сохранением, опустив заполнение параметров BAPI. В таком виде выдает  результат "не ок". При замене на commit work and wait - выдает ok.
 
  CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
    EXPORTING
      goodsmvt_header  = lmmdocheader
      goodsmvt_code    = lgmcode
      testrun          = abap_false
    IMPORTING
      goodsmvt_headret = lmmdocheader_ret
      materialdocument = lmblnr
      matdocumentyear  = lmjahr
    TABLES
      goodsmvt_item    = lt_mmdocitems
      return           = lt_bapiret.
 

  COMMIT WORK.
 
  SELECT SINGLE *
    INTO mkpf
    FROM mkpf
    WHERE mblnr = lmblnr.
 
  IF sy-subrc = 0.
    WRITE: / 'ok'.
  ELSE.
    WRITE: / 'не ok'.
  ENDIF.
 
WRITE:/ lmblnr.

прошу прощения не корректно скопировал.
выборка из мкпф конечно же по полному первичному ключу
  SELECT SINGLE *
    INTO mkpf
    FROM mkpf
    WHERE mblnr  = lmblnr
      and mjahr = lmjahr.

Комментарий от  

Денис Озорнов

  |  25 ноября 2014, 12:23

"Я Пастернака не читал, но осуждаю...
...
И как мать, и как женщина ...."

Скажите, пожалуйста, а вы всегда, когда вам сказать по существу нечего, начинаете известных людей цитировать, что бы скрыть отсутствие аргументов?

Комментарий от  

Олег Точенюк

  |  01 декабря 2014, 23:22

прошу прощения не корректно скопировал.
выборка из мкпф конечно же по полному первичному ключу
  SELECT SINGLE *
    INTO mkpf
    FROM mkpf
    WHERE mblnr  = lmblnr
      and mjahr = lmjahr.

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