Заметки старого АБАПника
Производительность на стандартной, сортированной и хешированной внутренних таблицах.
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
Реклама, что ли: sapland.ru/books/rekomendatsii-po-optimizatsii-programm-na-yazike-abap.html там есть найденные на просторах SCN принципы организации внутренних таблиц, ну это чтобы не замерять, то что смысла замерять нет.
Комментарий от
Александр Дублин
| 31 октября 2014, 12:16
Олег Точенюк 31 октября 2014, 00:44
"Оказывается, время поиска в хешированной таблице таки зависит от размера" - Таки не может, хеш-функция, на то и функция что она определяет положение записи, но ваше утверждение звучит так, что в зависимости от значений 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
Денис Озорнов 18 ноября 2014, 09:51
На мой не скромный взгляд: тест по хэшу ни о чем.
1) скорость измерения для хэш-таблы не коррелирует линейно с числом строк в таблице
2) речь идет о микросекундах, т.е. скорее всего это погрешности связанные с накладными расходами на обслуживание работы с таблой собственно, а не на поиск.
3) для чистоты замеров стоит исключить перекладывание найденных данных, использовав вместо INTO конструкцию TRANSPORTING NO FIELDS
4) если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы.
ЗЫ: Непонятно про рекламируемую книгу: зачем она, если есть первоисточники
sap-press.com/abap-performance-tuning_2092
Комментарий от
Денис Озорнов
| 18 ноября 2014, 10:05
Юрий Сычов 18 ноября 2014, 09:58
4) книга на русском. и она дешевле :)
2) - папа, зачем ты пьешь водку из горла? Возьми стакан!
- Сынок, папе не нужны посредники!
Комментарий от
Юрий Сычов
| 18 ноября 2014, 11:39
Денис Озорнов 18 ноября 2014, 10:05
1) очень печально, если программер не может читать на английском хотя бы тех.литературу
2) - папа, зачем ты пьешь водку из горла? Возьми стакан!
- Сынок, папе не нужны посредники!
далеко нам уже до индусов и остальных - те книги пачками выпускают.
Комментарий от
Денис Озорнов
| 19 ноября 2014, 09:36
Юрий Сычов 18 ноября 2014, 11:39
печально то, что в СНГ только 2 нормальные книги на русском: Виталия Поцелуева и Олега Точенюка.
далеко нам уже до индусов и остальных - те книги пачками выпускают.
Изданная книга это конечно хорошо, но был ли у нее тех.редактор? На примере статей этого ресурса по ABAP, можно сказать, что они не подвергаются рецензированию и редактуре (да какая редактура, если даже орфографические и синтаксические ошибки в статьях не вычищены?)
Комментарий от
Олег Точенюк
| 19 ноября 2014, 21:14
Денис Озорнов 19 ноября 2014, 09:36
Вы уж простите, я книгу Точенюка не читал. Но я читал его заметки по производительности с сайта sapforum.biz. Могу сказать, что там были моменты, которые, на мой взгляд, являются скорее уж вредными советами. Т.е. модель "дешево и сердито" конечно хороша, но не стоит забывать про "кроилово ведет к попадалову".
Изданная книга это конечно хорошо, но был ли у нее тех.редактор? На примере статей этого ресурса по ABAP, можно сказать, что они не подвергаются рецензированию и редактуре (да какая редактура, если даже орфографические и синтаксические ошибки в статьях не вычищены?)
По повожу технического редактора, ну я писал, Александры Дублин и Яков Михалыч Басок редактировали, Василий Ковальский вроде как рецензировал, но если для вас это ни о чем не говорит, то фиг с ним, оригинал тоже подойдет, хотя именно это издание я не читал. Но если вы думаете что мне было нечего делать, просто пересказать своими словами приведенную вами ссылку, то я тоже не возражаю.
PS: По поводу статей, именно статей тут по абапу их вообще-то мало (кажется 2), вы наверное имеете в виду авторские колонки/блоги. Их конечно же кроме автора вряд ли кто редактирует. Кстати, сделайте свою колонки, а мы почитаем...
Комментарий от
Олег Точенюк
| 19 ноября 2014, 21:23
Денис Озорнов 18 ноября 2014, 09:51
На мой не скромный взгляд: тест по хэшу ни о чем.
1) скорость измерения для хэш-таблы не коррелирует линейно с числом строк в таблице
2) речь идет о микросекундах, т.е. скорее всего это погрешности связанные с накладными расходами на обслуживание работы с таблой собственно, а не на поиск.
3) для чистоты замеров стоит исключить перекладывание найденных данных, использовав вместо INTO конструкцию TRANSPORTING NO FIELDS
4) если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы.
ЗЫ: Непонятно про рекламируемую книгу: зачем она, если есть первоисточники
sap-press.com/abap-performance-tuning_2092
Вы представляете что такое хеш доступ и как он реализуется при построении индекса? Вообще-то скорость доступа зависит не от длинны ключа (ну если мы не ассемблерный код хеш-функции анализируем и такты процессора с внутренними стеками да длину команд высчитываем), а от качества используемого алгоритма - хеш функции. Чем больше коллизий у алгоритма расчета тем медленнее поиск, так как выполняются различные дополнительные методы обхода коллизий и т.д.
PS: Не я понимаю что простое сложение байт строки в 10 символов и строки в 20 выполняется дольше, но мы то про базы данных, а не про что быстрее посчитается на уровне процессора и памяти.
Комментарий от
Олег Точенюк
| 19 ноября 2014, 21:26
Олег Точенюк 19 ноября 2014, 21:14
Ну вы их читали, но по факту так ничего в примеры кроме вот этого вот: "являются скорее уж вредными советами" не привели, поэтому беседа как бы ни о чем. Хотя я предложил вам ранее это сделать на конкретных примерах, где по вашему или совет не тот или граната не той системы.
По повожу технического редактора, ну я писал, Александры Дублин и Яков Михалыч Басок редактировали, Василий Ковальский вроде как рецензировал, но если для вас это ни о чем не говорит, то фиг с ним, оригинал тоже подойдет, хотя именно это издание я не читал. Но если вы думаете что мне было нечего делать, просто пересказать своими словами приведенную вами ссылку, то я тоже не возражаю.
PS: По поводу статей, именно статей тут по абапу их вообще-то мало (кажется 2), вы наверное имеете в виду авторские колонки/блоги. Их конечно же кроме автора вряд ли кто редактирует. Кстати, сделайте свою колонки, а мы почитаем...
Комментарий от
Денис Озорнов
| 20 ноября 2014, 11:27
Олег Точенюк 19 ноября 2014, 21:23
Занятное замечание: "если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы"
Вы представляете что такое хеш доступ и как он реализуется при построении индекса? Вообще-то скорость доступа зависит не от длинны ключа (ну если мы не ассемблерный код хеш-функции анализируем и такты процессора с внутренними стеками да длину команд высчитываем), а от качества используемого алгоритма - хеш функции. Чем больше коллизий у алгоритма расчета тем медленнее поиск, так как выполняются различные дополнительные методы обхода коллизий и т.д.
PS: Не я понимаю что простое сложение байт строки в 10 символов и строки в 20 выполняется дольше, но мы то про базы данных, а не про что быстрее посчитается на уровне процессора и памяти.
Возможно, что с развитием ядра. алгоритм изменился. Но ранее было так.
Про то что "мы про базу данных" - это вообще чушь. мы как раз не про базы данных, а про то, что выполняется на сервере приложений.
Комментарий от
Денис Озорнов
| 20 ноября 2014, 12:28
Олег Точенюк 19 ноября 2014, 21:14
Ну вы их читали, но по факту так ничего в примеры кроме вот этого вот: "являются скорее уж вредными советами" не привели, поэтому беседа как бы ни о чем. Хотя я предложил вам ранее это сделать на конкретных примерах, где по вашему или совет не тот или граната не той системы.
По повожу технического редактора, ну я писал, Александры Дублин и Яков Михалыч Басок редактировали, Василий Ковальский вроде как рецензировал, но если для вас это ни о чем не говорит, то фиг с ним, оригинал тоже подойдет, хотя именно это издание я не читал. Но если вы думаете что мне было нечего делать, просто пересказать своими словами приведенную вами ссылку, то я тоже не возражаю.
PS: По поводу статей, именно статей тут по абапу их вообще-то мало (кажется 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
Олег Точенюк 19 ноября 2014, 21:23
Занятное замечание: "если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы"
Вы представляете что такое хеш доступ и как он реализуется при построении индекса? Вообще-то скорость доступа зависит не от длинны ключа (ну если мы не ассемблерный код хеш-функции анализируем и такты процессора с внутренними стеками да длину команд высчитываем), а от качества используемого алгоритма - хеш функции. Чем больше коллизий у алгоритма расчета тем медленнее поиск, так как выполняются различные дополнительные методы обхода коллизий и т.д.
PS: Не я понимаю что простое сложение байт строки в 10 символов и строки в 20 выполняется дольше, но мы то про базы данных, а не про что быстрее посчитается на уровне процессора и памяти.
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
Денис Озорнов 21 ноября 2014, 09:49
Собственно вот цитата из курса 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
Денис Озорнов 20 ноября 2014, 12:28
для анализа взята версия 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? Ведь, согласно хелпу, как раз в этом случае программа будет гарантировано ждать, когда же объекты доедут в БД.
Я могу искать и дальше, но я не буду этого делать по той же причине почему не буду вести здсь блог\колонку: мне за это не платят зарплату.
Ну на самом деле замеры проводились не на одной системе, на разных конфигурациях, короче где был доступ там и гонял программки. Технически после запросов делался SELECT * FROM <таблица>, типа а прочитайка всю таблицу снова. Вообще-то в документе и книжке представлялись результаты, а не методики измерений. Так что это, как мне кажется, замечание по тому чего в документе нет :-)
2. В книге про "FOR ALL ENTRIES" формулировка почти такая же, с парой тестовых примеров при пустой таблицы в условии. Возможно ваше замечание и упрощает формулировку, но кроме вас никто не написал об этом.
3. Ну что в JOIN не используется буферизация по тексту есть отдельное замечание в разделе работы с буферизированными таблицами. Вообще-то буферизацию можно отключать/включать, хотя конечно проблемы при таких операциях могут быть уже вашими, о чем SAP собственного говоря и предупреждает.
4. Ну почему же, вот вы считаете что общего рецепта нет, я считают что он есть. Замечание касалось массовой заливки/обновления данных в системе. Переполнить транзакшин лог? Но, как раз данное замечание и касалось того, что нужно выполнять периодические промежуточные фиксации результатов работы. Делать это после каждого обработанного объекта, страдает производительность, делать это в конце обработки всех объектов, тоже страдает производительность + технические проблемы журнала транзакции. Поэтому там ровно сказано то, что периодически фиксируйте ваши изменения. Рецепт фиксации мой, чисто опытный. Если правильно помню, то там же сказано, что в каждом случае нужно смотреть на что обновляется и как.
5. Ну вот этот пункт это не у меня "шикарно", это у вас "шикарно", я бы данное замечание приводил как яркую иллюстрация к фразе зачем нужны книги русском и пользе чтения английских текстов. Вы вот сослались на справку, она по абапу на английском, вот только проблема в том, что вы прочитав, подумали что поняли все правильно. По факту же, вы абсолютно не поняли разницы между синхронными и асинхронным коммитом (в книге на русском я таки это описал более развернуто чем в документе с форума). Данный вывод я делаю по вашей фразе "программа будет гарантировано ждать, когда же объекты доедут в БД". Так вот синхронный коммит не будет ждать, пока объекты куда-то доедут, он просто подождет выполнения модулей/подпрограмм обновления и ВСЕ! Последующее чтение после выполнения синхронного коммита периодические будет выдавать сообщение об отсутствии записи в базе данных. Вариантов обхода этой ситуации много, я поделился тем, который для себя определил как самый быстрый при массовой вставке объектов в БД, при условии, что последующий объект ссылается на предыдущий.
И в завершении "почему не буду вести здсь блог\колонку: мне за это не платят зарплату" - Ну это вам к Дублину, он на такие темы любит объяснить кто и где заблуждается :-)
Комментарий от
Олег Точенюк
| 22 ноября 2014, 17:31
Юрий Сычов 18 ноября 2014, 11:39
печально то, что в СНГ только 2 нормальные книги на русском: Виталия Поцелуева и Олега Точенюка.
далеко нам уже до индусов и остальных - те книги пачками выпускают.
Комментарий от
Денис Озорнов
| 22 ноября 2014, 21:42
Олег Точенюк 22 ноября 2014, 17:14
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
Денис Озорнов 19 ноября 2014, 09:36
Вы уж простите, я книгу Точенюка не читал. Но я читал его заметки по производительности с сайта sapforum.biz. Могу сказать, что там были моменты, которые, на мой взгляд, являются скорее уж вредными советами. Т.е. модель "дешево и сердито" конечно хороша, но не стоит забывать про "кроилово ведет к попадалову".
Изданная книга это конечно хорошо, но был ли у нее тех.редактор? На примере статей этого ресурса по ABAP, можно сказать, что они не подвергаются рецензированию и редактуре (да какая редактура, если даже орфографические и синтаксические ошибки в статьях не вычищены?)
Комментарий от
Олег Точенюк
| 23 ноября 2014, 01:09
Денис Озорнов 22 ноября 2014, 21:42
По пордяку:
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
2. Да какие там нафиг бизнес процессы то? Есть объект, надо обновить данные, есть BAPI, нет BAPI смотрим что есть и выполняем задачу. Зачем же усложнять и так сложное.
3. Ну вот я и говорю, что прочитать вы прочитали, да только не поняли что. Вот и думаете, что синхронный апдейт вам обещает обновление на уровне БД, хотя там такого нет, но вы то прочитали и поняли так как поняли.
Комментарий от
Денис Озорнов
| 23 ноября 2014, 01:37
Олег Точенюк 23 ноября 2014, 01:09
1. Ну это у вас какие-то упрощенные представления о методике кеширования записей на уровне СУБД. Не хана же, все в память затаскивать. Да и еще раз, тестирование проводилось на разных системах с разной загрузкой и это усредненные числа. Можете предложить свои варианты расчета производительности, хотя конечно вам за это ж не заплатят, поэтому вряд ли.
2. Да какие там нафиг бизнес процессы то? Есть объект, надо обновить данные, есть BAPI, нет BAPI смотрим что есть и выполняем задачу. Зачем же усложнять и так сложное.
3. Ну вот я и говорю, что прочитать вы прочитали, да только не поняли что. Вот и думаете, что синхронный апдейт вам обещает обновление на уровне БД, хотя там такого нет, но вы то прочитали и поняли так как поняли.
И не надо приплетать хану. Есть некий объем кэша. Читаем больше чем есть в нем места? происходит вытеснение реже читаемых данных из кэша.
2) Какие? да например те же самые, что вы описывает, когда пытаетесь через чтение блокировок поймать ранее созданный документ\запись справочника и т.д.
3) Ну если для вас мало синхронного апдейта, несмотря на вполне исчерпывающее описание (зря не потрудились прочитать, там сказано, что вольется именно в базу, если не используете апдейт таск модули, а есть и такие BAPI), то есть еще и LOCAL UPDATE. Вот в них уже даже апдейт таски выполняются в том же процессе. Или вы опять буде спорить с хелпом сапа?
Комментарий от
Денис Озорнов
| 23 ноября 2014, 09:55
Олег Точенюк 23 ноября 2014, 01:09
1. Ну это у вас какие-то упрощенные представления о методике кеширования записей на уровне СУБД. Не хана же, все в память затаскивать. Да и еще раз, тестирование проводилось на разных системах с разной загрузкой и это усредненные числа. Можете предложить свои варианты расчета производительности, хотя конечно вам за это ж не заплатят, поэтому вряд ли.
2. Да какие там нафиг бизнес процессы то? Есть объект, надо обновить данные, есть BAPI, нет BAPI смотрим что есть и выполняем задачу. Зачем же усложнять и так сложное.
3. Ну вот я и говорю, что прочитать вы прочитали, да только не поняли что. Вот и думаете, что синхронный апдейт вам обещает обновление на уровне БД, хотя там такого нет, но вы то прочитали и поняли так как поняли.
Комментарий от
Олег Точенюк
| 23 ноября 2014, 13:39
Денис Озорнов 23 ноября 2014, 01:37
1) Методику кеширования например оракла я знаю, это LRU алгоритм. Вам знакомо такое понятие? Т.е.'least recently used'. Т.е. вытеснение менее нужных данных при заполнении кэша, см. например docs.oracle.com/cd/B28359_01
И не надо приплетать хану. Есть некий объем кэша. Читаем больше чем есть в нем места? происходит вытеснение реже читаемых данных из кэша.
2) Какие? да например те же самые, что вы описывает, когда пытаетесь через чтение блокировок поймать ранее созданный документ\запись справочника и т.д.
3) Ну если для вас мало синхронного апдейта, несмотря на вполне исчерпывающее описание (зря не потрудились прочитать, там сказано, что вольется именно в базу, если не используете апдейт таск модули, а есть и такие BAPI), то есть еще и LOCAL UPDATE. Вот в них уже даже апдейт таски выполняются в том же процессе. Или вы опять буде спорить с хелпом сапа?
2. Ну это вы решили тут совместить написанное в двух разных местах. А в описании есть отдельно процесс массового обновления объектов и процесс определения наличия объекта в БД, в данном случае через блокировку.
3. Для меня конечно мало, мне как вы говорите зарплату не платят чтобы разжевывать вам перевод справки системы, который вы не очень понимаете. Так что дальше будьте уверены что синхронного апдейта и включенного локального обновления вам будет достаточно для появления объекта в БД.
Комментарий от
Олег Точенюк
| 23 ноября 2014, 13:44
Денис Озорнов 23 ноября 2014, 09:55
Кстати, пожалуйста, изложите ваше толкование того, что изложено в хелпе. Только пожалуйста, каждую вашу сентенцию снабдите ссылкой на цитату из хелпа. Пока что, вы только голословно утверждаете, что мое понимании не верно, не смотря на приложенную однозначно трактуемую цитату из документации. Как мне кажется, документация в этом случае все определяет однозначно. Развейте-таки мои сомнения!
PS: Да и это не толкование, это фактическая проверка того как это работает. Тоже в свое время свято верил что синхронный апдейт гарантирует появления объекта на уровне БД. Пока не понял как же это по факту работает. Будет время можете проверить, программка пишется быстро, а вот результат вас я думаю немного озадачит. Можете там покомбинировать синхронный/асинхронные апдейты, локальное обновление и т.д.
Комментарий от
Денис Озорнов
| 23 ноября 2014, 14:42
Олег Точенюк 23 ноября 2014, 13:44
Зачем вам цитаты из хелпа? Вы их уже привели, но вы их не очень понимаете судя по всему. Толкование расписано в книге, ну вам то она не нужна, а переписывать сюда то что там уже написано, как то не вижу смысла.
PS: Да и это не толкование, это фактическая проверка того как это работает. Тоже в свое время свято верил что синхронный апдейт гарантирует появления объекта на уровне БД. Пока не понял как же это по факту работает. Будет время можете проверить, программка пишется быстро, а вот результат вас я думаю немного озадачит. Можете там покомбинировать синхронный/асинхронные апдейты, локальное обновление и т.д.
Комментарий от
Денис Озорнов
| 23 ноября 2014, 14:46
Олег Точенюк 23 ноября 2014, 13:39
1. Замечательно что вы ее знаете, т.е. вы предполагаете что кеша хватит на полную заливку таблицы MSEG в память, путем удаления вообще всего ранее считанного? Не ну думайте так дальше.
2. Ну это вы решили тут совместить написанное в двух разных местах. А в описании есть отдельно процесс массового обновления объектов и процесс определения наличия объекта в БД, в данном случае через блокировку.
3. Для меня конечно мало, мне как вы говорите зарплату не платят чтобы разжевывать вам перевод справки системы, который вы не очень понимаете. Так что дальше будьте уверены что синхронного апдейта и включенного локального обновления вам будет достаточно для появления объекта в БД.
2) Да. именно. Не бывает сферических коней в вакууме. Задача вполне утилитарна. И совет в данном случае не покрывает всего поля возможностей
3) Как я вижу хелп и курсы вы не примаете как аргумент. Адекватного аргумента не приводите, кроме голословных утверждений "я знаю" и рекламы вашего опуса. Я, например потрудился и прочел хотя бы часть вашего труда на форуме и высказал вполне обоснованные сомнения в его адекватности. Опровергнуть вы их не можете. Как говорили математики: ЧТД.
Комментарий от
Олег Точенюк
| 23 ноября 2014, 18:50
Денис Озорнов 23 ноября 2014, 14:46
1) Кажется вы не понимаете суть алгоритма LRU. Объясню. Если вы делаете пример на mseg, а потом делаете его же полное перечитывание что бы забить кэш, то на выходе есть не нулевая вероятность, что в кэше остануться те же данные, на которых вы тестируете. И это будет вне зависимости от размера кэша БД. Как-то так.
2) Да. именно. Не бывает сферических коней в вакууме. Задача вполне утилитарна. И совет в данном случае не покрывает всего поля возможностей
3) Как я вижу хелп и курсы вы не примаете как аргумент. Адекватного аргумента не приводите, кроме голословных утверждений "я знаю" и рекламы вашего опуса. Я, например потрудился и прочел хотя бы часть вашего труда на форуме и высказал вполне обоснованные сомнения в его адекватности. Опровергнуть вы их не можете. Как говорили математики: ЧТД.
2. Не вопрос, как раза если задача утилитарная, то и опыт ее экстраполируется на другие утилитарные задачи. Этот опыт и рекомендации и описаны. Применять их или нет, ваше право.
3. Тоже не вопрос, пребывайте и дальше в своих заблуждениях, опровергается это очень просто тестовым примером, минут за 30. Проводка документов ММ через стандартную BAPI, с последующим чтением проведенного документа. Что и описано в примерах. Для вас это не убедительно, опять же ваше право. Я это проверил практически, вы чисто теоретически прочитав английский курс/справку и не поняв что там написано, пытаетесь меня убедить в обратном. Ну тоже не вопрос, считайте и дальше что вы правильно поняли написанное в курсе/справке.
Комментарий от
Олег Точенюк
| 23 ноября 2014, 18:50
Денис Озорнов 23 ноября 2014, 14:42
Т.е. ваш слив защитан? Привести цитату из хелпа вы не можете. Все остальное - ваши измышления?
Комментарий от
Олег Точенюк
| 23 ноября 2014, 18:55
Александр Дублин 23 ноября 2014, 00:55
Так почитайте :-)
Комментарий от
Денис Озорнов
| 23 ноября 2014, 20:09
Олег Точенюк 23 ноября 2014, 18:50
1. Не вопрос. Про сферический кэш СУБД убедили, он бесконечный и в нем все остается.
2. Не вопрос, как раза если задача утилитарная, то и опыт ее экстраполируется на другие утилитарные задачи. Этот опыт и рекомендации и описаны. Применять их или нет, ваше право.
3. Тоже не вопрос, пребывайте и дальше в своих заблуждениях, опровергается это очень просто тестовым примером, минут за 30. Проводка документов ММ через стандартную BAPI, с последующим чтением проведенного документа. Что и описано в примерах. Для вас это не убедительно, опять же ваше право. Я это проверил практически, вы чисто теоретически прочитав английский курс/справку и не поняв что там написано, пытаетесь меня убедить в обратном. Ну тоже не вопрос, считайте и дальше что вы правильно поняли написанное в курсе/справке.
3) Т.е. так и записываем объяснить что же я не правильно понял в хелпе - вы не можете.
Комментарий от
Денис Озорнов
| 23 ноября 2014, 20:09
Олег Точенюк 23 ноября 2014, 18:50
Ну зачем же мне приводить вашу же ссылку. Ссылка правильная, а вот что в ней написано вы понимаете не правильно. Оставайтесь в своем заблуждении и далее.
Комментарий от
Денис Озорнов
| 23 ноября 2014, 20:21
Олег Точенюк 23 ноября 2014, 18:50
1. Не вопрос. Про сферический кэш СУБД убедили, он бесконечный и в нем все остается.
2. Не вопрос, как раза если задача утилитарная, то и опыт ее экстраполируется на другие утилитарные задачи. Этот опыт и рекомендации и описаны. Применять их или нет, ваше право.
3. Тоже не вопрос, пребывайте и дальше в своих заблуждениях, опровергается это очень просто тестовым примером, минут за 30. Проводка документов ММ через стандартную BAPI, с последующим чтением проведенного документа. Что и описано в примерах. Для вас это не убедительно, опять же ваше право. Я это проверил практически, вы чисто теоретически прочитав английский курс/справку и не поняв что там написано, пытаетесь меня убедить в обратном. Ну тоже не вопрос, считайте и дальше что вы правильно поняли написанное в курсе/справке.
Комментарий от
Олег Точенюк
| 23 ноября 2014, 20:25
Денис Озорнов 23 ноября 2014, 20:21
И это я еще не упомянул про ваш вредный совет использовать установку-снятие блокировки, вместо простого вызова ENQUEUE_READ
Комментарий от
Олег Точенюк
| 23 ноября 2014, 20:33
Денис Озорнов 23 ноября 2014, 20:09
1) Еще раз. Не бесконечный кэш. В кэше остаются данные которые читаются чаще всего. Прочитали строку А при поиске с индексом 5 раз - Она осталась в кэше. прочитали ту же строку но с поиском в фуллскане - она все равно останется, как часто читаемая.
3) Т.е. так и записываем объяснить что же я не правильно понял в хелпе - вы не можете.
3. Ну выражаясь вашими словами, мне за это лично вы не платите,поэтому не очень понимаю почему я вам обязан что-то объяснять так чтобы вы именно поняли. Я и так достаточно за бесплатно вас проконсультировал, вы считаете что я пишу ерунду, еще десяток людей который участвовали в написании книги тоже несут пургу. Ну дальше как бы смысла продолжать. Кстати про описанную ниже функцию чтения записей блокирования для проверки объектов, это пять... вы даже не очень понимаете сами что предлагаете, ну да это не важно вы же я так понял прожженный абапер. Любитель циклических вызовов разных ФМ-ов. Не возражаю, пишите и дальше в таком же духе. Да в и вообще оптимизация вещь вредная, кому не хватает купят сервер по мощнее, базу побыстрее и т.д.
Комментарий от
Олег Точенюк
| 23 ноября 2014, 20:35
Денис Озорнов 23 ноября 2014, 20:09
Т.е. ответить на вопрос "что же именно я понял не правильно?" вы не в состоянии? Ок. Так и зафиксируем. Объяснить - не способны.
Комментарий от
Денис Озорнов
| 23 ноября 2014, 20:39
Олег Точенюк 23 ноября 2014, 20:25
Ну что вам сказать... с чего вы решили что блокировка на создаваемый объект будет в буфере блокирования при создании записи? В справке прочитали? А при изменении, ну замерьте что быстрее будет установка/снятие блокировки или чтение таблицы? Вы кстати ее как читать будете? В цикле пока там запись не пропадет? Успехов... так сказать.
Комментарий от
Денис Озорнов
| 23 ноября 2014, 20:41
Олег Точенюк 23 ноября 2014, 20:33
1. А с чего вы решили что я там в примерах да еще на разных системах, с разным количеством пользователей, а записи точно в кэще будут, потому что они наиболее частыми оказались? Не ну опять же не вопрос, теоретизируйте дальше, у меня практические выкладки и проверены они на разных системах с разными интервалами выполнения запросов. Но для вас это ни что. Я вообще-то вас не убеждаю.
3. Ну выражаясь вашими словами, мне за это лично вы не платите,поэтому не очень понимаю почему я вам обязан что-то объяснять так чтобы вы именно поняли. Я и так достаточно за бесплатно вас проконсультировал, вы считаете что я пишу ерунду, еще десяток людей который участвовали в написании книги тоже несут пургу. Ну дальше как бы смысла продолжать. Кстати про описанную ниже функцию чтения записей блокирования для проверки объектов, это пять... вы даже не очень понимаете сами что предлагаете, ну да это не важно вы же я так понял прожженный абапер. Любитель циклических вызовов разных ФМ-ов. Не возражаю, пишите и дальше в таком же духе. Да в и вообще оптимизация вещь вредная, кому не хватает купят сервер по мощнее, базу побыстрее и т.д.
Комментарий от
Денис Озорнов
| 23 ноября 2014, 20:47
Олег Точенюк 23 ноября 2014, 20:25
Ну что вам сказать... с чего вы решили что блокировка на создаваемый объект будет в буфере блокирования при создании записи? В справке прочитали? А при изменении, ну замерьте что быстрее будет установка/снятие блокировки или чтение таблицы? Вы кстати ее как читать будете? В цикле пока там запись не пропадет? Успехов... так сказать.
И кстати говоря, я совершенно спокойно могу ставить блокировки на не существующий в базе объект.
И соответственно у вас опять в мануале чушь написана: вы предлагаете с помощью установки блока проверить, а создался ли этот док, при том, что при его создании как раз блокировки не будет вообще, а система на не существующие номера блокировки ставить позволяет.
Для хранения блокировок и их чтения\записи используются си-щные функции ядра. Поэтому БД там не читается. Вам исходник приведенного мной ФМ кинуть, если вы не в силах его посмотреть в системе сами?
Комментарий от
Денис Озорнов
| 23 ноября 2014, 20:59
Олег Точенюк 23 ноября 2014, 20:33
1. А с чего вы решили что я там в примерах да еще на разных системах, с разным количеством пользователей, а записи точно в кэще будут, потому что они наиболее частыми оказались? Не ну опять же не вопрос, теоретизируйте дальше, у меня практические выкладки и проверены они на разных системах с разными интервалами выполнения запросов. Но для вас это ни что. Я вообще-то вас не убеждаю.
3. Ну выражаясь вашими словами, мне за это лично вы не платите,поэтому не очень понимаю почему я вам обязан что-то объяснять так чтобы вы именно поняли. Я и так достаточно за бесплатно вас проконсультировал, вы считаете что я пишу ерунду, еще десяток людей который участвовали в написании книги тоже несут пургу. Ну дальше как бы смысла продолжать. Кстати про описанную ниже функцию чтения записей блокирования для проверки объектов, это пять... вы даже не очень понимаете сами что предлагаете, ну да это не важно вы же я так понял прожженный абапер. Любитель циклических вызовов разных ФМ-ов. Не возражаю, пишите и дальше в таком же духе. Да в и вообще оптимизация вещь вредная, кому не хватает купят сервер по мощнее, базу побыстрее и т.д.
Т.е. все в итоге как и остальное у вас "хелп не правильный, я знаю лучше". Ок. знайте. Только другим не надо впаривать свои кривые знания. Я думаю, те кто читали эту дискуссию все про вас поняли. От вас не поступило ни одного потвержденного документацией аргумента, только хамство в итоге
Комментарий от
Олег Точенюк
| 24 ноября 2014, 01:22
Денис Озорнов 23 ноября 2014, 20:47
На создаваемый - естественно не будет.
И кстати говоря, я совершенно спокойно могу ставить блокировки на не существующий в базе объект.
И соответственно у вас опять в мануале чушь написана: вы предлагаете с помощью установки блока проверить, а создался ли этот док, при том, что при его создании как раз блокировки не будет вообще, а система на не существующие номера блокировки ставить позволяет.
Для хранения блокировок и их чтения\записи используются си-щные функции ядра. Поэтому БД там не читается. Вам исходник приведенного мной ФМ кинуть, если вы не в силах его посмотреть в системе сами?
Комментарий от
Александр Дублин
| 24 ноября 2014, 11:27
Олег Точенюк 23 ноября 2014, 18:55
Саша он не будет читать, он английский знает... а я его не знаю, поэтому приходится все что прочитано проверять на практике :-)
...
И как мать, и как женщина ...."
Комментарий от
Денис Озорнов
| 24 ноября 2014, 16:28
Олег Точенюк 23 ноября 2014, 20:35
За бесплатно - лично для вас НЕТ. Учите английский и матчасть. Сторону копания я вам указал, дальше вопрос закрыт :-)
1) Вы так и не сказали , в каком месте я не правильно прочитал хелп, упомянув при этом что "место правильное, но понимаю я его не правильно"
2) пример из вашей статьи я воспроизвел с COMMIT WORK AND WAIT. Все работает как часы согласно хелпа.
3) вы сделали выводы о том как я работаю , приписав мне слова, которых я не говорил (начиная о сферических кэшах(при том, что я дал ссылку на конкретную статью об оракле) и заканчивая выводами о моем стиле программирования, при том что не видели не единой строки моего кода)
4) Чего стоит ваш пассаж ниже в камменте о хэш-табле, когда вы как-то незаметно начинаете говорить о БД, не смотря на то что речь шла именно о хэш-табле, т.е. объекте которого в БД просто нет.
Прекрасный показатель вашего уровня дискуссий и ваших статей\книг и лекций.
PS: по поводу отсылки к Василию Ковальскому: я вообще в экстазе. Так и представляю, как Василий, читая курс BC414 на космодаминской набережной, долго рассказывает то, как изложено в хелпе и курсе, а потом на вопрос слушателя "А вот Точенюк в своей книге и статьях говорит, что синхронное обновление в хелпе определено не верно" удивленно смотрит на вопрошающего.
Ага.
Комментарий от
Олег Точенюк
| 25 ноября 2014, 00:12
Денис Озорнов 24 ноября 2014, 16:28
Это я за просто так вывел косяки в вашей заметке. Вы же на это не смогли привести ни одного аргумента.
1) Вы так и не сказали , в каком месте я не правильно прочитал хелп, упомянув при этом что "место правильное, но понимаю я его не правильно"
2) пример из вашей статьи я воспроизвел с COMMIT WORK AND WAIT. Все работает как часы согласно хелпа.
3) вы сделали выводы о том как я работаю , приписав мне слова, которых я не говорил (начиная о сферических кэшах(при том, что я дал ссылку на конкретную статью об оракле) и заканчивая выводами о моем стиле программирования, при том что не видели не единой строки моего кода)
4) Чего стоит ваш пассаж ниже в камменте о хэш-табле, когда вы как-то незаметно начинаете говорить о БД, не смотря на то что речь шла именно о хэш-табле, т.е. объекте которого в БД просто нет.
Прекрасный показатель вашего уровня дискуссий и ваших статей\книг и лекций.
PS: по поводу отсылки к Василию Ковальскому: я вообще в экстазе. Так и представляю, как Василий, читая курс BC414 на космодаминской набережной, долго рассказывает то, как изложено в хелпе и курсе, а потом на вопрос слушателя "А вот Точенюк в своей книге и статьях говорит, что синхронное обновление в хелпе определено не верно" удивленно смотрит на вопрошающего.
Ага.
Комментарий от
Денис Озорнов
| 25 ноября 2014, 11:57
Олег Точенюк 25 ноября 2014, 00:12
2. Код в студию, что вы и как проверяли. Если боитесь за авторство схематично блоки кода.
Привожу пример с асинхронным сохранением, опустив заполнение параметров 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
Денис Озорнов 25 ноября 2014, 11:57
Тестовый пример, исключительно для иллюстрации, создает движение ММ, после чего проверяет наличие созданного документа в 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
Александр Дублин 24 ноября 2014, 11:27
"Я Пастернака не читал, но осуждаю...
...
И как мать, и как женщина ...."
Комментарий от
Олег Точенюк
| 01 декабря 2014, 23:22
Денис Озорнов 25 ноября 2014, 12:21
прошу прощения не корректно скопировал.
выборка из мкпф конечно же по полному первичному ключу
SELECT SINGLE *
INTO mkpf
FROM mkpf
WHERE mblnr = lmblnr
and mjahr = lmjahr.