Ни что не предвещало беды, программа работала как надо, но на определенном объеме данных начинала выдавать ошибку HTTP_NO_MEMORY.
Рубрика: Ошибки
SQ01 Устаревший инфо-запрос
После редактирования инфо-набора, инфо-запрос при попытке редактирования может выдавать сообщение - "Разница между запросом и инфо-набором". А при попытке изменения произойдет дамп "Exception condition "NOT_FOUND" triggered"
HR_MAINTAIN_MASTERDATA не сохраняет отдельные записи ИТ при проведении мероприятий
Была поставлена задача - проводить мероприятия в системе при помощи HR_MAINTAIN_MASTERDATA. Мероприятия работали корректно. После проведения все инфо-типы записывались. Однако, при проведении увольнения инфо-типы 0000 и 0001 не сохранялись. Ошибки при этом никакой не возникало, на первый взгляд все отрабатывало штатно. Пробовал менять параметр LUW_MODE, сбрасывал буфер перед вызовом ИТ, запускал в отдельном потоке и прочее. Результата это никакого не дало.
Нашел два выхода из этой проблемы:
Читать далее «HR_MAINTAIN_MASTERDATA не сохраняет отдельные записи ИТ при проведении мероприятий»
Ошибка CX_HRPA_VIOLATED_PRECONDITION
В ходе расширения отчета HRULPAY2, возникла необходимость вставить запись в Z инфо-тип. Для этого был использован ФМ HR_INFOTYPE_OPERATION. Но программа упорно падала в дамп в классе CL_HRPA_MASTERDATA_FACTORY, а именно при атрибуте a_is_initialized = true. Данный флаг взводился при заполнении DAQ поля стандартным ФМ HR_RU_DAQ_PAY2_ADR, и возможности его убрать не было.
Быстрое гугление показало, что данная ошибка была из-за проблем с PS буфером, и его надо просто инициализировать заново. Для этого можно было использовать подпрограмму do_nothing (sapfp50p) . Однако, дамповать стала уже после нее.
Дамп по тайм ауту
Если программа вываливается по тайм ауту, то один из способов устранения проблемы( считаем, что оптимизация не возможна) является использование ФМ TH_REDISPATCH .
Также можно изменить параметр 'rdisp/max_wprun_time' в транзакции RZ11. Параметр применяется без перезагрузке сервера.
Ошибка в отладчике при одинаковом наименовании глобальных и локальных переменных.
Сегодня прилетел дамп по одной старой разработке. Собственно ошибка была понятна по описанию, суть не в ней. Но чтобы убедиться точно, в правильности выводов по ошибке, решил поставить точку в коде недалеко от строки дампа и посмотреть что да как.
Каково же было мое удивление, что находясь внутри цикла LOOP AT gt_data ASSIGNING <fs_data>. Field-symbol в отладчике отображался как еще не присвоенный, при этом было видно, что на самом деле с ним было все в порядке. Т.е. проблема была именно в отладчике и именно с <fs_data>. Остальные Field-symbol работали корректно, инклуд активировался без ошибок.
Читать далее «Ошибка в отладчике при одинаковом наименовании глобальных и локальных переменных.»
Добавление нового поля в таблицу с записями.
В результате тестирования разработки оказалось, что при выборке из Z* таблицы выбираются не все значения.
В таблице у нас находятся 15 записей. В se11 мы видим, что у пяти записей в поле del_flag = 'X', у десяти del_flag пустой.
Далее выполняем три запроса к таблице:
|
1 2 3 |
SELECT * FROM z_table INTO TABLE @DATA(lt_table_1). SELECT * FROM z_table INTO TABLE @DATA(lt_table_2) WHERE del_flag = @abap_true. SELECT * FROM z_table INTO TABLE @DATA(lt_table_3) WHERE del_flag @abap_true. |
В результате имеем: все 15 записей в таблице lt_table_1, 5 записей с del_flag = 'X' в таблице lt_table_2 и ТОЛЬКО 5 записей в таблице lt_table_3 с del_flag 'X'. Куда же делись еще 5 записей, которые должны были выбраться в таблицу ls_table_3 ?
CALL TRANSACTION ‘QE01’
В одной из программ потребовалось вызвать транзакцию QE01 ввести там данные и вернуться в исходную транзакцию. Но в некоторых случаях вместо возврата в исходную программу, возвращалиcь в меню SAP. Оказалось, что транзакция в некоторых случаях вызывала другие при помощи LEAVE TO TRANSACTION, причем экраны были практически идентичны. А LEAVE очищает стек вызовов, и после выполнения транзакции просто некуда было возвращаться. В нашем случае, если были частичные партии, вызывалась транзакция QE14. Проблему решили тем, что теперь мы вызываем две транзакции в зависимости от наличия частичных партий QE01 и QE14 соответственно. Проблема с возвратом в исходную программу решена.
Ошибка при экспорте данных в XLSX из ALV
При выгрузке данных стандартным функционалом ALV возникла ошибка Удаленный компонент: часть/xi/sharedStrings.xml
Оказывается, проблема была в спецсимволах в строках для вывода. В нашем случае, ALV не понравилась решетка #. Решение на май 2018 только одно - удалить спецсимволы или попытаться выгрузить в другой формат.
SELECT … FOR ALL ENTRIES и DISTINCT
Необходимо было разобраться, почему запрос не получает все записи из БД. Сам запрос довольно простой. Казалось бы, ничего не предвещало беды.
Запрос:
|
1 2 3 4 5 6 7 8 9 10 11 |
SELECT vbelv, posnv, vbtyp_n, rfmng, FROM vbfa INTO CORRESPONDING FIELDS OF TABLE @DATA(lt_vbfa) FOR ALL ENTRIES IN @lt_vbap WHERE vbfa~vbelv = @lt_vbap-vbeln AND vbfa~posnv = @lt_vbap-posnr AND ( vbfa~vbtyp_n = 'R' OR vbfa~vbtyp_n = 'h' ). |
Однако вместо 15-ти записей возвращалось всего 5.