Регулярно (каждый час) подчитываю данные из GLPCA и группирую суммы в разрезе МВП, МВЗ, Бизнес-сферы и т.д. в своей таблице.
Одновременно с этим, в GLPCA регулярно доливаются данные (по несколько десятков записей в секунду - система работает...)

Однако полученные суммы не соответствуют тому, что мы видим в отчете KE5Z.
Думаю, что это происходит потому, что при считывании очередной порции данных я натыкаюсь на незакоммиченные данные, которые затем возможно откатываются.

Вопрос:
Может ли кто подсказать, как читать только закоммиченные записи?

Да, вообще-то, незакоммиченные данные видно только из того DB LUW, в котором они вставлялись.

Вы лучше откройте секрет, откуда Вы знаете, какие строки из GLPCA уже были обработаны, а какие нет? Уж не по CPUDT+CPUTM ли?

Не совсем понятно, что Вы понимаете под словом "обработаны"

Я не то, чтобы знаю, а скорее подозреваю, что или пропускаю некоторые записи, или читаю такие, которые затем откатываются (например при возникновении ошибки во время заливки данных)

Так я думаю потому, что, насколько я знаю, - записи в GLPCA не изменяются и не удаляются, а только добавляются.

Если в двух словах, то я храню ID последней прочитанной записи и в каждом очередном сеансе чтения читаю, начиная с записи, имеющей ID большей чем тот, что был запомнен. Читаю далее до конца.
После обработки последней записи снова запоминаю ее ID.

Насколько я знаю, по умолчанию, САП читает таблицы из БД вообще никак их не блокируя, то есть не обращая внимания на те блокировки, которые могут быть установлены на эти записи (например блокировка при вставке или апдейте). Отсюда я делаю вывод о том, что выполняется "грязное чтение"

Кажется сам нашел ответ на свой вопрос...
Вот выдержка из хелпа по ABAP:

Uncommitted read (or dirty read)

A program using an "uncommitted read" to read data does not set locks on data objects and does not obey them. For this reason, programmers must bear in mind that their programs might read data that has not yet been finally written to the database with a database commit and could thus still be deleted from the database by a database rollback. "Uncommitted read" is the default setting in the SAP-system for the isolation level.


Committed read

A program using a "committed read" to read data obeys the locks on data objects. This means that programmers can be sure that their programs will read only data which has been finally written to the database with a database commit. You can set the isolation level in the SAP-system to "committed read" by calling the function module DB_SET_ISOLATION_LEVEL. The next database commit or rollback will reset the isolation level to its default setting, as will calling the function module DB_RESET_ISOLATION_TO_DEFAULT.

Вот про это и был вопрос. Хорошо, что не время


Не скажу за все БД, конечно, но у нас на Oracle всё путём (проверено экспериментально). SAP выставляет максимальный уровень изоляции/сериализации на уровне DB LUW и базисники мне когда-то говорили, что они не знают даже, как это поменять.

Могу ошибаться, но, кажется, экстрактор в BW читает эту таблицу используя как-раз время, но с безопасным интервалом.

А в каком смысле интервал может быть "безопасным" ?

Да, если процесс обновления застопорился, то запись может появиться существенно позже, чем cpudt.

Из хэлпа:


Для GLPCA по умолчанию безопасный интервал - 2 часа.

Ах. если бы Вы дали ссылку в интернете (подозреваю, что это с сайта help.sap.com), где можно все это подробно прочитать...

Очень уж подробно не получится, но вот ссылки:
http://help.sap.com/saphelp_nw04/helpdata/en/37/4f3ca8b672a34082ab3085d3c22145/content.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/44/9821620553053de10000000a1553f6/content.htm
А главное, не забывайте про гугл, который эту цитату легко находит.

Уважаемый sibrin. На сколько точно выбираются данные при помощи CPUDT+CPUTM для таблиц EKBE COVP?
Если установить интервал безопасности в 5 10 20 минут для CPUDT+CPUTM станет чтение данных абсолютно точным?